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Abstract 

TIm  «m  of  ml4faM  systems  is  eridely  spread  today,  sad  iavobas  very  lsr(s  sad 
sophistic  st  sd  prognose.  la  additioa  to  tbs  coastrsiats  imposed  oa  “regmlar* 
my  large  programs,  real-time  easy  large  programs  are  snbjected  to  striageat 
real-time  r  nastraiats  that  the  desagaer  tries  to  meet,  to  satisfy,  aad  to  validate. 
Those  secy  large  psograam  (systems)  are  of  a  very  complicated  asters,  aad  seed 
special  ossthodolngiag  This  reviser  trim  to  saauaarise  the  methods,  approaches, 
techaiqees  aad  tools  srhich  ass  seed  today  dariag  a  real  time  system's  life  cycle. 
The  reviser  deals  erith  three  impoctaat  phases  of  a  real  tfaae  systssn:  the  dasiga 
phase,  the  implsmeatatioa  phase,  aad  the  emUdatioa  phase. 
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Chapter  1 

Introduction 


The  commordaliwtiw  ud  coat  ndKte  of  ■kneoapvtea  has  rmlud  in 
•a  increased  «m  of  r— I  til  system*  ■  a  wide  nrkjr  of  folds.  Traditional 
hsrdwsn  qiipaat  has  bow  roplaeod  by  compaterised  systems,  wkick  have 
providsd  a  won  loadblo  aad  expandable  owbnoiwt.  Military,  indnatrial  sad 
medical  ippfcorioi  baplamaat  wool  of  their  required  control  functions  u- 
taf  coo^rtobod  goal  Ibw  oyot—  Sxampiae  of  onck  applications  an  mnckar 
power  plaat  control,  lad— tilal  float  control,  medical  monitoring,  digital  iy- 
by-wfce  avionics  aad  map  on  dsHvacy  syetaam.  At  tko  noo  of  sack  oyotens  kao 
tpwd,  tko  timing niprinm wta  ban  harems  men  striagaat,  aad  tko  reliability 

Dmigniag  root  thw  oystoaw  io  tkoofkt  to  bo  oaa  of  tko  most  complex  pro¬ 
gramming  activities.  Whoa  bnildiag  a  awdal  of  ascending  complexity  ia  doriga- 
iag  compntor  ayotoam  [54],  one  starts  witk  ooqnontlal  programming,  increasing 
tko  complexify  to  tko  level  of  coacoiroat  programming,  sad  fa  ally  adding  tke 
timing  notion  to  nock  tko  lord  of  real  time  programming.  Combining  tko  reli- 
abQty  mqakromwto  aad  tbs  complexity  involved,  resnlts  ia  a  severely  restricted 
mvironment.  Pertbarmors,  aot  as  ia  tbs  asqaoatial  sad  concurrent  program¬ 
ming,  nohthao  systsms  on  faaplomoatotioa  dependent.  A  program  that  has 
bow  sweated  successfully  wkw  imp  lorn  wlsd  ia  oao  environment,  doss  not 
aoconorily  satisfy  tbs  constraint  of  oaotbsr  onvironmoat.  Chaagoo  ia  tbs  cora- 
pmtmr  hardwan,  commnakation  network,  oporatiag  system  or  poripkoral  device 
rsopansi  time,  may  ckaage  tko  system  behavior  to  o  point  where  it  does  not 
satisfy  a  particular  program's  requirements  any  aton. 

This  review  trim  to  saauaarise  tbs  ntothodo,  approaches,  techniques  aad 
tools  which  an  seed  today  daring  a  real- time  system's  life  cycle.  Tko  review 
deals  witk  three  important  phases  of  e  real-time  system:  tke  design  phase,  the 
implementation  phase,  sad  tke  validation  phase.  (Another  important  phase, 
the  maintenance,  is  aot  included  ia  this  review).  A  chapter  is  dedicated  to  each 
of  tke  above  phases. 
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The  goal  of  this  review  is  not  to  criticise  the  different  appeoachee  which  are 
summarised  here,  rather  it  is  to  highlight  interesting  aspects  which  concern  the 
life-cycle  of  a  real-time  system.  A  strong  emphasis  is  layed  on  new  approaches. 
Some  of  the  approaches  are  described  in  more  details  than  others.  Methods 
which  are  eery  widely  used  nowaday,  are  sometimes  briefly  mentioned,  while  new 
(and  sometimes  even  immature)  methods  are  reviewed  in  depth.  The  reason  is 
certainly  not  the  importance  of  the  more  detailed  ones,  bat  the  limitations  of 
this  review  doe  to  its  nature  and  goals. 


Chapter  2 


Design  Methods  for  Real 
Time  Programs 

2.1  General 

Many  approaches  and  methods  are  need  in  designing  software.  This  chapter 
tries  to  captwre  past  and  preeant  worts  which  are  used  in  d— jgning  real-time 
software.  Some  commonly  need  methods  are  not  reviewed  hen.  Jackson  and 
Warniar  design  methods  aie  data  stractnie  oriented  methods,  primarily  suited 
for  program  level  design.  Both  can  neither  handle  the  decomposition  into  mod¬ 
ules  or  tasks,  nor  are  they  appropriate  for  real-time  systems.  Higher  Order 
Software  methods  ese  functional  dacomposhion,  but  fail  to  address  tasking  end 
synchronisation  issues.  Thus,  two  major  methods  am  examined:  a  structured 
design  method,  and  an  event-baaed  design  method.  The  methods  are  divided 
further  according  to  the  modeling  they  enforce,  and  to  the  system  statement 
and  analysis  approaches  they  adopt. 

The  next  section  of  this  chapter  deals  with  requirement  specification  tech¬ 
niques  and  approaches.  The  third  section  describee  structured  design  methods, 
mainly  process  baaed  methods,  and  soma  problematic  issues  concerning  the  ap¬ 
plication  of  these  methods.  The  fourth  section  describes  issue*  that  arise  when 
applying  a  graph-based  design  method.  The  fifth  section  compares  the  above 
conventional  methods  versus  the  operational  method  which  is  more  implemen¬ 
tation  oriented.  The  last  section  of  this  chapter  reviews  FSA  (Finite  State 
Automata)  modeling  of  real-time  systems,  mainly  the  Petri  Nats  Theory  and 
soma  segmentations  applied  to  it. 


2.2  Requirement  Specification  Methods 

A  lot  of  software  engineering  research  has  addressed  the  problem  of  defining 
complete  and  consistent  requirements  specification  methodologies.  In  this  sec¬ 
tion,  a  review  of  two  methodologies  is  given,  along  with  an  example  of  how 
to  implement  a  third  methodology.  The  principles  of  these  methodologies  are 
important  to  real-time  software  design,  as  they  are  to  other  fields.  Although 
some  methods  emphasise  only  the  documentation  part  of  this  early  phase  of  de¬ 
sign,  other  methods  provide  good  tools  for  structure  construction  and  feasibility 

2.2.1  PSL  /  PSA 

The  PSL  (Problem  Statement  Language)  and  PSA  (Problem  Statement  Ana¬ 
lyser)  are  computer  aided  tools  [32]  especially  designed  for  requirement  speci¬ 
fication  statement  and  documentation  of  information  processing  systems.  This 
tool  emphasises  the  front  end  of  the  system  for  specifying  the  requirements,  and 
produces  a  large  variety  of  documents  describing  the  database  for  the  system 
specifications  entered  so  far.  The  database  is  built  by  steps,  and  hierarchy  can 
be  imposed.  The  basic  structure  in  the  system  description  in  the  OBJECT,  to 
which  PROPERTIES  can  be  attached  with  PROPERTY  VALUES.  The  objects 
are  connected  by  RELATIONSHIPS,  while  both  objects  and  relationships  may 
be  classified  with  TYPES.  PSL  produces  upon  demand  eight  types  of  reports 
for  system  description: 

X.  System  I/O  Flow  -  The  interaction  between  the  target  system  and  its 
environment. 

2.  System  Structure  •  Objects  hierarchies. 

3.  Data  Structure  -  Internal  relationships  between  data  objects. 

4.  Data  Derivation  •  The  relationships  between  processes  and  data  objects. 
8.  System  Sise  and  Volume. 

3.  System  Dynamics  -  System  “behavior"  within  time. 

7.  System  Properties  •  Distinguishing  remarks. 

8.  Project  Management  •  Project  schedules  etc. 

In  addition  PSA  Produces  the  following  report  typee: 

1.  Record  of  modifications  applied  to  the  database. 

2.  Reference  reports  •  Names,  properties,  dictionary. 

3.  Summary  reports  -  Structure  and  flow. 
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4.  Auijrm  reports  •  CntnU  comparison,  date  processing  interactions,  pro- 
cawing  chain. 


For  a  design  of  a  real-time  system,  this  computerised  tool  can  be  need  for 
documentation,  bnt  no  benefits  can  be  gained  for  the  continuation  of  the  design 
phase,  aad  for  the  verifiability  of  the  design. 

2.2.2  SREM 

SREM  is  a  requirement  engineering  methodology  [4],  which  was  developed 
for  the  Balistk  Missile  Defense  Advanced  Technology  Center  by  TRW.  The 
methodology  adopts  the  functional  hierarchy  requirements  of  MIL-STD-490,  in 
which  each  process  is  divided  to  functions,  each  of  these  further  divided  to  sub- 
functions,  aad  so  on.  The  hierarchy  imposes  validation  difficulties,  especially 
when  trying  to  exercise  sub-sub- function  through  input  sequences. 

Seven  Key  Concepts  at  SREM 

1.  A  testable  requirement  must  be  specified  in  terms  of  data  input  and  out¬ 
put.  The  reason  for  this  concept  is  that  a  real-time  software  is  tested  by 
inputting  a  MESSAGE  aad  extracting  the  results  of  its  processing  (an 
output  MESSAGE)  aad  the  content  of  memory. 

2.  Processing  PATHs  are  sequences  which  do  not  contain  loops,  defined  in 
terms  of  input  MESSAGES,  output  MESSAGES,  processing  steps,  and 
date  utilised  aad  produced. 

S.  VALIDATION  POINTS  are  places  where  a  test  may  be  performed  in  terms 
of  variables  measured  on  the  PATH.  Defining  the  testable  variables  on 
validation  points  assures  testability  and  unambiguity  of  the  requirements. 

4.  R-NET  is  an  integration  of  all  the  PATHs  that  procsw  a  given  type  of 
stimulus,  into  a  Requirement  NETwork.  This  is  a  graph  model  of  the 
computation  and  the  flow.  Five  types  of  nodw  are  used  in  the  graph: 
processing  step  node  (ALPHA),  input/output  interface  node,  and/or  flow 
node,  selector  node,  and  validation  point  node.  The  unidirectional  arcs 
represent  the  data  flow  between  the  nodw. 

5.  RSL  -  a  formal  language  for  specification  of  requirements. 

4.  REVS  -  an  automated  tool  which  speeds  up  and  validates  the  require¬ 
ments'  completenew  and  consistency. 

7.  Methodology  STEPS  -  which  produce  intermediate  products  obeying  eval¬ 
uation  criteria  for  each  step. 
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Methodology  Step*  and  Their  Products 
Step  1.  Translation. 

1.  banes  addressed: 

•  Adequacy  of  subsystem  performance  requirements  (DPSPR)  for 
generating  processing  requirements. 

•  Early  baselining  of  the  functional  requirements. 

•  Budgeting  and  scheduling  the  activities. 

2.  Activities  in  this  step: 

•  RSL  originating  requirements  entered  into  REVS  database. 

•  Generation  of  R-NETs,  DATA,  ALPHAS,  with  traceability  back 
to  DPSPRs. 

•  Analysis  of  consistency  and  completeness  of  the  requirements, 
e  Generation  of  DPSPR  problems  report. 

•  Budgeting  and  scheduling  further  activities. 

3.  Products: 

e  DPSPR  problem  report, 
e  R-NETs. 
e  ALPHAS, 
e  DATA. 

e  Functional  traceability, 
e  Plans. 

Step  2.  Decomposition. 

1.  Issues  addressed: 

e  Preliminary  definition  of  the  performance  requirements, 
e  The  incorporation  of  the  processing  to  satisfy  the  subsystems 
constraints  into  the  processing  requirements. 

2.  Activities  in  this  step: 

e  Identification  of  the  form  of  the  performance  requirements, 
e  Specification  of  the  data  collected  at  validation  points  (software 
variables). 

e  Recording  the  decisions  made,  to  relate  accuracy  and  timing  re¬ 
quirements  back  to  DPSPRs. 

3.  Products: 

•  Refined  RSL. 

e  Performance  traceability. 

•  Validation  points. 
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Step  8.  Allocation. 

1.  Issues  addressed: 

•  Determining  the  sensitivity  of  PATH  performance  to  DPSPRs. 

•  Establishing  the  tradeoffs  between  accuracy  and  timing  of  the 
different  PATHs,  then  selecting  an  allocation  which  is  not  overly 
restricted. 

2.  Activities  in  this  step: 

•  After  establishing  the  requirements  of  each  of  the  PATHs,  the 
requirement  and  its  test  are  written  in  RSL. 

•  In  complicated  systems  a  functional  simulator  is  developed. 

3.  Products: 

e  Performance  sensitivity. 

e  Performance  statement. 

e  Process  Performance  Requirements  (PPR). 

e  Functional  simulation. 

Step  4.  Analytical  Feasibility  Demo. 

1.  Issues  and  Activities: 

•  Example  algorithms  are  implemented  to  demonstrate  that  criti¬ 
cal  procsssing  requirements  can  be  satisfied.  This  is  done  before 
attempting  the  design  of  an  algorithm  for  the  real-time  software. 

e  A  direct  check  is  provided  by  the  above,  the  algorithms  that 
satisfy  the  PPR,  in  fact  meet  the  originating  requirements  -  the 
DPSPR. 

2.  Products: 

•  Example  algorithms. 

e  Simulator. 


Conclusion 

The  SREM  methodology  allows  specifying  complete  and  consistent  requirements 
to  both  the  system  and  its  subsystems.  The  R-NET  graph  model  resembles  more 
advanced  models  of  FSA,  and  allows  better  visibility  of  relations  and  testability 
properties.  Yet,  most  of  the  performance  decisions  and  the  structure  built-up 
are  manual,  and  depends  highly  on  the  designer’s  skills.  The  use  of  a  functional 
simulator  to  verify  performances  is  misleading  due  to  common  mode  errors  (see 
section  4.4.2),  and  to  the  high  cost  of  providing  it  on  time. 
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2.2.3  Example:  A-7  Requirements  Specification 

Another  approach  for  requirements  specification  is  introduced  in  the  redesign 
of  the  avionics  software  of  the  A-7  Navy’s  aircraft.  The  method  introduced 
(18]  is  used  by  the  Naval  Research  Lab  and  the  Naval  Weapon  Center.  The 
flight  program  which  was  documented  is  a  part  of  the  Navigation  and  Weapon 
Delivery  System  of  the  aircraft.  The  program  has  high  accuracy  requirements 
and  stringent  real-time  constraints.  It  receives  input  data  from  the  aircraft 
sensors  and  from  operational  switch  panels,  and  controls  many  devices  (e.g.  the 
Inertial  Measurement  System,  the  Head-Up  display,  the  Doppler,  Barometer 
etc.).  The  program’s  main  tasks  are  to  calculate  the  navigation  information 
and  to  control  the  weapon  delivery. 

Requirements  Document  Objectives 

The  objectives  of  a  document  that  integrates  the  requirements  of  a  software 
system,  as  interpreted  by  Pam  as  et  al,  are  listed  below. 

1.  Specify  external  behavior  only,  without  implying  a  particular  implemen¬ 
tation. 

2.  Specify  constraints  on  the  implementation,  especially  the  details  of  hard¬ 
ware  interfaces  (usually  the  case  with  computer  embedded  systems). 

S.  Installing  changes  should  be  easy. 

4.  Ability  to  serve  as  a  reference  tool. 

5.  Record  forethought  about  the  life  cycle  of  the  system. 

8.  Characterise  acceptable  response  to  undesired  events. 

Requirements  Document  Design  Principles 

1.  State  questions  before  trying  to  answer  them. 

2.  Separate  concerns:  organise  the  document  such  that  any  project  member 
could  concentrate  on  a  well-defined  set  of  questions. 

3.  Formality  should  be  used  as  much  as  possible,  in  order  to  obtain  precision, 
consistency,  and  completeness. 

Techniques  for  Describing  Hardware  Interfaces 

•  Organisation  of  Data  Items:  A  data  item  is  a  unit  concerning  an  input  or 
an  output  that  changes  value  independently  of  other  inputs  or  outputs. 
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•  SpmboUc  Names  (for  Data  Item*  and  Value*) :  Data  item*  contain  two 
kinds  of  information:  arbitrary  details  and  essential  characteristics.  Es¬ 
sential  information  most  be  expressed  in  a  way  that  wonld  allow  using  it 
from  the  rest  of  the  document,  without  referencing  the  arbitrary  details. 

e  Templates  for  Value  Descriptions:  Describing  each  data  item  in  ad  hoc 
fashion  produces  inconsistencies  between  documents.  The  existence  of 
templates  provides  the  following  features:  values  description  is  easier, 
there  is  a  consistency  between  documents,  and  standards  of  completeness 
may  be  applied  uniformly  to  all  items  of  the  same  type. 

e  Input  Dot s  Items  Described  as  Resources:  The  input  data  items  are  de¬ 
scribed  as  if  using  an  inventory  of  available  resources  to  solve  the  problem. 
This  description  is  independent  of  software  use. 

e  Output  Data  Items  Described  as  Effects:  Most  of  the  output  data  items 
are  described  as  effects  on  external  hardware. 

Techniques  for  Describing  Software  Functions 

e  Organising  bp  Functions:  Functional  hierarchy  is  adopted  as  for  MIL- 
STD-490.  Two  cists ee  of  software  functions  are  distinguished:  periodic 
functions  and  sporadic  (on-demand)  functions.  The  distinction  is  useful 
in  cases  where  different  performance  aad  timing  constraints  are  imposed 
for  each. 

•  Output  Values  as  Functions  of  Conditions  and  Euents:  A  condition  is  a 
predicate  that  characterises  some  aspect  of  the  system  for  a  measurable 
period  of  time.  An  event  occurs  when  a  condition  changes  its  truth-value. 
Hence,  events  are  associated  with  instants  of  time,  whereas  conditions  are 
with  time  intervals.  Events  designate  start  and  stop  of  periodic  functions, 
and  they  trigger  sporadic  functions. 

•  Consistent  Notation  for  Operating  Conditions:  Maintaining  a  consistent 
notation  has  crucial  importance  in  requirements  document.  The  A-7  ex¬ 
ample  provides  a  notations!  standard  in  which  conditions,  events  and  text 
macros  are  well  defined  and  distinguished. 

•  Using  Modes  to  Organise  and  Simplifp:  Modes  (Le.  rlarrirt  of  system 
states)  help  in  simplifying  and  organising  the  hierarchical  structure,  by  in¬ 
troducing  a  higher  abstraction  level.  Furthermore,  a  transition  list  which 
includes  entries  from  one  mode  to  another,  allows  detection  of  illegal  tran¬ 
sitions  as  well  as  serving  as  a  control  tool 

e  Special  Tables  for  Precision  and  Completeness:  The  A-7  document  uses 
two  special  tables  to  express  information  precisely  and  completely.  A 
condition  table  is  used  to  define  an  output  value  upon  a  specified  active 

11 


mo de  ud  i  wdkki  that  occro  witka  tbt  ■oil.  AamHUbbakom 
whsa  *  sporadic  faactioa  ahooid  U  performed,  or  when  a  periodic  function 
■keild  bs  started  or  stopped,  with  iwptct  to  tht  currently  active  mod*. 


List  of  Uadeeired  Events 

A  rleasilrstimi  of  udnind  rotate,  m  pwt  by  Parana,  it  thatched  btlow.  At 
mentioned  before,  a  acceptable  response  to  toy  at  that  occuraacee  should  bt 
epeciled,  tad  aot  left  to  tht  prograaaaMr  to  itwtl 

1.  Resource  ftihut. 

•  Ttmponry. 

•  PriMMd. 

2.  Incorrect  iaptt  dote. 

•  Dtteeted  by  whhj  hptt  otiy. 

•  Dtteeted  by  comparison  with  internal  date. 

•  Dtteeted  by  ottr  rtoHtiof  hr  itdt  a  mistake 

•  Detected  by  tttr  from  iacomct  output. 

3.  Incorrect  iateraal  date. 

•  Detected  fay  iateraal  iroattettacy. 

•  Detected  by  cotapariaoa  with  iapat  data. 

•  Detected  by  aatr  froat  iacorrtct  oatpat. 

2.3  Process  Based  Structured  Design  Methods 

2.S.1  Theoretical  Description 

A  theoretical  examination  of  the  proctor  baaed  methods  it  given  ia  [26]. 

Typea  of  Prorata  Baaed  Methodolofioa 

Mok  diatiagaiahet  two  typea  at  deaiga  methodologies  ia  applying  the  traditioaal 
proctaa  baaed  daaigm  method: 

1.  Tht  strive!  processor  methodology:  Each  proctat  is  aasamtd  to  have  a 
dedicated  procttaoc  (ate  alao  [34]).  The  objective  of  thia  approach  ia  to 
have  a  proves  boaaded  execution  time,  while  aaaeriag  propertiea  of  no- 
deadlock,  faimees,  etc.  Timiag  coastraiats  are  therefore  left  to  be  solved 
by  the  achedaliag  strategy.  This  aoletioa  dote  aot  address  iaseee  seek 
aa  commoalcatioa  bottle-neck,  which  thee  haa  to  be  address  id  through 
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•  Da—apoktka  of  Ik  r— pattlfc—1  nf  hnm m te, 


•  Ad*«a*rr  of  tk*  Mtwwcy  coated  teockaa km. 
h  ardor  to  nalyor  lfc»  oyteaa  >Awiir  Mot  hfcdw  tk  foBowtef  ■oto 

•  Lot  tip  ko  tk*  «■>  a#  yriofc  put—  ia  tk*  qri>— 

•  UM,  ki  Um  Ht  of  opnradte  ptn—  it  Um  ay*—. 

•  MimUpUM: 

•  Back  pwf  ftiit  tripb  wkon:  «  kwta  Ik*  caay— ioi 

taa*  of  Ik*  proeow,  p  d—o*w  tk*  parted,  aad  dt  daaotoa  Ik*  d**dlh*. 

•  >H  :  ti  <  4i  <  *• 

lllk*agk**p*ndtc  prat—  ka*ao*p*rilr  parted,  item  *>aad*  far  Ik*  awtetl 
tef—r  te  wkkk  il  te  all-ad  to  appaar. 

34.3  Scheduling  Using  a  P  rococo  Bated  Modal 


A  a*c***ary  tudilte*  for  ek*dili*|  i*  Ikal  Ik*  mm  of  afl  atttttjr  factor*  of  tk* 
proctete*  i*  ten  Ikaa  tk*  —bar  of  arailabte  proe— on.  la  otter  words: 

£<(*/*)  <  #  of  avail  proc—aro. 

Tk*  ackadaltef  te  wl  tk—  «awrir— — t  rotate**  that  aU  tk*  cnateraiat  of  tk* 
partedk  aad  tk*  rporadk  proe*****  an  cootiaaoa*ly  satteAad.  Tk*  aoO  g*a- 
oral  *rk*dall*t  contract  irate**  two  *ck*dai*ra:  aa  off-Ua*  ackadater  wkkk 
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a  n»  tiai  wfcriilir  which  is 
paficjr  dictated  by  lit  ol-lbo.  Fbr  theoretical 

it  bee  special  bight 


hlok 
caa  predict  the 


The  aoa  obviooe  ochodaHag  algorithm  is  the  "eariiaot  doadlbo*  algorithm. 
The  echodahr  dwomc  to  tamte  the  procam  whom  doodBaa  is  the  eortieet 
to  happao,  A  better  approach  ia  to  am  a  cchadmMag  policy  which  chooam  the 

the  *laaet  alack*  algorithm,  whore  the  alack  of  a  pro  cam  at  time  t  ie  dadoed  ae 
the  ■■■imam  tioae  which  a  roe- time  echodahr  caa  delay  it,  withoat  dieobayiag 
the  nooetrabte 


»Uck{Pi,t)  m  mas(d(t)  -  t  -  e(t),0) 

Moh  proaoe  the  foOowbg  theeraom  coacmaiog  a  riagle  proceaeor  achedalar: 

•  The  ieoet  eiock  algorithm  cao  he  mad  ac  a  totally  no  Hoe  optimal  ma  time 
achedalar,  coder  the  aeoampliria  that  the  echedolar  caa  choooo  to  preempt 
a  process,  by  aay  other  wady  pro  cam,  at  any  integral  thaa  betaare 


e  Where  there  era  mataal  ear  baton  roaetrabte,  it  ie  impoaeibla  to  lad  a 
totally  no  Mat  uptime!  raa  Ibn  achedalar. 

•  Lot  Mi-MpUM,  be  aabstaaoeafaprocaaeee  modal,  aad  lot 
be  the  aombal  alack  of  each  process.  Replace  every  Tt  -  (*,*,<)  €  Jd. 
hy  a  periodic  -  («.p{,<)  ,  e««h  that  p{  -  «»*(*,*  +  1)  aad  <  -  «. 
■  Id*  (which  ie  created  by  the  repUcaaaaat)  caa  be  aaccearfally  echedaled, 
thaa  Jd  caa  be  echedaled  withoat  a  priori  knowledge  of  the  raqaaot  timee 
o I  Jd.. 


la  a  awlti  proceaeor  aariro— not,  (probably  asiag  a  leadasvooe  mecheeiem  to 
ayachrooioe  batwem  coouaaakaata)  the  earUsot  HeedHae  algorithm  may  fail 
Mok  caggaoto  it  caa  be  land  by  revfc iag  the  deadliam  dyaamicaQy,  ae  follows: 

1.  Sort  echedalbg  blocka  gaaaratad  ia  [0,L]  ia  reverse  topological  ordar. 

2.  laitiaHoe  the  deadHae  of  the  k’th  betaace  of  to  (k  -  1)*  +  d,. 
a.  Revise  the  deadHaae  b  reverse  topological  order  by 


d*-idm(d*,(d; -<:*->**)), 


h  aad  k *  are  acbadaUag  blocks. 


This  Bodiicatm  lUom  the  following  theorem: 

•  V»  feasible  schedule  waste  for  an  instance  of  model,  restricted  by  ten* 
desvous  constrainta,  then  it  can  be  scheduled  by  the  earliest  dead  line  al¬ 
gorithm,  modified  to  schednls  the  ready  process  which  isn't  blocked  by  a 
laadasvous,  and  baa  the  nearest  dynamic  deadline. 

3.3.3  Requirement  of  *  Structured  Deaign  Method 

A  structured  design  method  decomposes  its  modules  hierarchically.  When  ap¬ 
plied  to  a  real-time  system,  the  method  is  required  to  provide  the  following 

mv- 

1.  Dala-jlew-onieated  design.  A  structured  design  consists  of  two  main  com- 
ponoute:  (1)  Two  seta  of  criteria,  cohesion  and  coupling.  (2)  Top  down 
decomposition  of  n  system  into  modules.  The  objective  of  tbs  design  is 
to  produce  a  system  in  which  modules  have  high  coharion  and  low  cou¬ 
pling.  Is  order  to  ssamiue  these  properties,  data-flow  approach  in  appro¬ 
priate  [22],  showing  the  functional  modules  (tmns/emu),  the  data  flow 
between  them,  and  the  data  atoms  accessed  by  them.  Furthermore,  real¬ 
time  systeses  am  usually  data  flow  orient  ad.  Two  design  approaches  may 
be  distinguished: 

a  TVnas/ona  Centered  Design,  in  which  the  major  streams  of  data  are 
HwtUii  as  they  flow,  transformed  from  asternal  Input  to  external 

•  IVaaoaetioa  Centered  Design,  applicable  wham  the  date  flow  con¬ 
sists  mainly  of  control- information,  La.,  data  which  in  passed  to  a 
transform  initiates  an  action  (or  a  sequence)  based  on  the  incoming 

1.  Tosh  Synchro  aim  ties.  Two  kinds  art  mostly  sssd: 

e  Mutual  exclusion  :  shared  data  can  bo  concurrently  secerned  by  two 
or  mam  tasks,  while  the  ac'-ees  is  controlled  by  moans  of  semaphores. 

•  Croee  stmmlatioa  :  one  task  is  awaiting  a  signal  from  another  in  order 
to  proceed. 

1.  JWh  CeaMHMieoiiea.  M omega  communication  is  the  moot  commonly 
need  method.  Task  communication  can  bo  closely  con  plod  (a  reop  one  i  is 
exported  in  order  to  continue),  or  loosely  coupled  (with  the  use  of  massage 
queues).  A  manage  caneamor  that  lads  an  empty  queue,  waits  until  a 
meeesfe  arrives.  Them  am  three  ways  to  implement  the  communication: 

•  Using  the  operating  eyetem  primitives. 

e  Using  a  language  facilities  [2]. 


•  Uaiag  a  Kodak  which  prowidee  tka  aonrkaa  (itodf  aaiag  operating 
eyatai a  prtmitwae,  aa  implemented  tm  MASCOT  ckuMb). 


4.  hfermmtiem  Hidimf  Genoa? 1  Tkk  concept  (by  Parana)  is  powarfal  in 
laadtag  to  a  highly  aoklu  atractare.  Tk  idw  k  tkat  sack  hay  it  known 
oaljr  to  mi  modaio,  kn  Ik  akrad  date  k  kept  to  ■inimnaa.  Modako 
aaa  tkadw  men  aotf  contained  (thaa  ama  aaodilahla  aad  aora  maia- 
lahahk).  Tko  cook  of  tkk  approach  k  ia  tka  oaarkoa d  in  arraoaiag  a  data 
etmekoro  via  a  inaction  rathar  tkaa  directly. 


I.  State  Dependency.  Moat  approackaa  prorida  dependency  of  taking  an 
action  on  inpat  data.  Soma  (oapeciaDy  foand  ia  tranaaction  cantarad  ap¬ 
proack  kapkaaaatationa)  fail  to  allow  dapaadaacy  of  taking  an  action  on 
tka  ayatam'a  atata.  A  atractarad  daaigi  method  akeald  incorporata  atata 
dapandancy  «  wall  aa  data  dapaadaacy. 


a  .9.4  DARTS 

DARTS  k  a  Daaign  Approack  for  Boat-time  Syatama,  propooad  in  (16]  aa  an 
ataakn  of  tka  oldar  atractarad  daaign  matkoda,  to  inclada  taak  atractaring  aa 
watt  aa  taak  interface  dalakiona.  DARTS  araa  developed  by  Ganoral  Ekctrk, 
and  waa  applied  to  two  projecta:  a  robot  oontrattar  aad  a  vkaon  ayatean.  Wkaa 
tko  papar  waa  wikUn  tka  robot  waa  abaady  in  tka  inlapation  pkaaa,  aad  tko 
application  of  tko  method  araa  ermaidarad  aarraaafaL  DARTS  ataato  aritk  tka 
ragakamanta  apadttcatian,  aad  ita  flaat  pkaaa  k  analysing  tka  data  low. 


I.  Depeadaacy  oa  I/O:  ff  th«  speed  »  dictated  by  a  alow  I/O  device,  then  a 

aaparmU  task. 


2.  Tima  Critical  Faactioas:  If  a  high  priority  ia  dtstimguiahsd  for  a  particular 
faactioa,  thaa  a  separata  task. 

S.  Conpatatioial  Raquiramaata :  If  a  faactioa  is  idaatifiad  to  hare  intaaaive 
computaiioas,  thaa  a  separate  task  -  to  allow  a  work  mods  of  span  cycles 


4.  FWactioaal  Cohesioa:  If  faactioas  an  fooad  to  be  closely  related,  that 
grouped  iato  oh  task,  to  ndace  system  overhead.  Witkia  a  task,  modules 
cub  be  dietiaguished  for  foactioaal  cokesiou  at  the  amdule  level. 

8.  Temporal  Cohesioa:  If  faactioas  an  fooad  to  be  triggered  by  the  same 
stimulus,  thaa  grouped  iato  oae  task,  dietiaguished  as  diffareat  modules 
withia  the  task. 


6.  Periodic  Exscutioa:  If  a  traaaform  aeeds  to  be  executed  periodically,  thaa 
^  separate  task,  activated  at  regular  thaa  iatervals. 


SM - 


‘huh  rimsBauuiiatliui  Ifnitnlu  A  typical  TClfcowtaias  a  data  slrac- 
aad  sa  aeeeas  precadun  to  that  structure.  The  access  procedun  cou- 
i  aba  the  mtual  rrrluafoa  aad  the  syurhrnaiuBtlim  foot  one,  which 
use  oparatiag  system  primitives.  The  TCM  always  ruas  oa  the  task 
iwvohes  it.  Two  dMhreet  types  of  TCli  an  provided  by  DARTS: 

MOM  -  Message  Coauaualcatioa  Module:  Supports  both  closely  cow- 


la  the 


of  loosely  cos- 


1.  A  daft*  low  between  tub  is  interpreted  —  one  of  the  following: 

•  A  loossljr  coupled  mssssg—  queue,  handled  by  an  MCM. 
e  A  cloeely  coupled  meeaage/reply,  handled  by  an  MCM. 
e  An  event  signal,  If  only  occurance  notification  is  required. 

2.  A  shared  data  store  is  handled  by  an  IHM. 

3.  A  task  that  waits  for  an  event,  may  need  a  TSM. 

Thik  Design 

Structured  Design.  Each  individual  task  represents  a  sequential  program. 
The  design  of  the  task  starts  with  the  low  analysis  at  the  task  level, 
followed  by  applying  one  of  the  two  possible  structured  design  approach- 
stated  above;  According  to  the  nature  of  the  task,  either  a  transform 
centered  design  approach  or  a  transaction  cantered  design  approach  is 
applied. 

State  dependency.  DARTS  us—  a  State  Transition  Manager  (STM),  designed 
—  a  TCM  of  the  IHM  type.  Th»  —a  table  *■  an iatained  *-y 

models,  hidden  from  the  calling  task.  While  responding  to  a  transition 
request,  the  request  validity  is  checked  by  the  aces—  procedure,  aad  when 
coals— d  the  models  sneent—  the  transition.  In  aid—  to  sneers  the 
etosnkity  of  the  transition  execution,  —  well  —  to  achieve  fa—  transit  ions, 
aa  approach  iararo— mended  by  lha  anther  in  TWa  idea  is  to  iaaea— 

the  task’s  priority  when  STM  is  —tired,  aad  re— ore  the  old  priority  when 
the  STM  is  exited. 

1-1.1  Task  Allocation  Schama  for  a  RaaMima  System 

As  mentioned  above,  many  design  methods  fail  to  adds—  the  task  coastrnctkm, 
aad  thaa  are  not  suitable  for  dseigning  real-time  ly-ims.  That  is  the  meson  for 
inc lading  the  following  —he—  (23]  in  this  review.  The  task  alloc— ioa  —heme 
was  developed  by  TRW,  and  w—  applied  aaccaaefaUy  ia  the  BMD  (Ballistic 
Missils  Dsfea— )  project. 

Port-to-Port  Execution  Time 

Software  tasks  ia  time-critical  real-time  systems  a re  asually  divided  into  several 
threads,  and  each  of  the  threads  meet  sathty  —  execetion-tia—  constraint,  de¬ 
moted  —  the  port-to-port  procss— ag  tin—.  In  the  above  application,  23  tasks 
were  divided  into  7  threads.  Exs cetioa  tuns  of  a  thread  conoioti  of  fair  compo- 


1.  Execution  time  of  the  task  on  the  processor  which  depends  on  the  task 
si—  and  the  processor  MIPs  rate. 
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Et  —  tita(ta»ki)/MIPi  rate  o f  the  proem or. 

2.  Tk*  artwork  and  operating  >yrttm  overhead  (NO),  which  k  need  for  con¬ 
currency  control,  integrity  checking,  recovery  check-point  update,  etc. 

S.  Inter- pro  cm  or  communication  ( IPC ),  which  k  higher  if  communicants 
reside  on  different  processors. 

4.  Waiting  time  (  WT)  which  k  consnmed  when  the  task  waits  in  the  proces¬ 
sor  enablement  qoene.  Thk  figure  depends  highly  on  the  sises  and  number 
of  tasks,  the  processor  load,  and  the  number  of  enablements.  (Especially 
H  large  tasks  are  Tgn**1  to  the  same  processor.) 

Therefore, 

Sr -£<(«()  + 1*0  +  IPC  +  WT. 

For  a  given  network,  NO  and  the  number  of  enablements  k  relatively  a 
constant.  Hence,  in  order  to  reduce  Et  the  following  steps  should  be  adopted: 

e  Reduce  WT:  large  tasks  should  be  assigned  to  different  processors. 

e  Reduce  IPC:  tasks  with  high  IPC  cost  with  each  other  should  be  assigned 

e  Reduce  Et:  large  tasks  should  be  assigned  to  processors  with  higher  MI  Pa 

rate. 

.Allocution  Mwhl 

The  above  rnuaidarstioaa  yield  the  following  sequence  of  activities  in  designing 
an  allocation  scheme: 

e  A  art  of  constraints  k  determined,  to  reduce  the  watting  time  and  the  task 
execution  time. 

e  A  cost  function  that  measures  the  IPC  cost  k  formulated. 

e  An  algorithm  that  searches  for  the  allocation  with  the  minimum  total  cost 
k  determined. 

The  above  activities  are  performed  in  the  following  method: 

1.  Information  k  entered  to  the  model  about  the  tasks  (sises,  execution  fre¬ 
quency  of  each  task,  number  of  data  units  exchanged  between  each  pair 
of  tasks)  and  the  network  (Inter- processor  distance,  constraints). 

2.  Constraints  are  imposed  on  the  model: 
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•  Task  preference  matrix:  Certain  tasks  (out  of  m)  can  b«  executed 
oaljr  om  specific  processor!  (oat  of  a).  These  restrictions  are  formu¬ 
lated  as  an  m  x  »  matrix  of  0's  and  l’s.  Xij  »  0  means  task  i  can't 
be  assigned  to  processor  j.  Xij  »  1  means  no  restriction  on  task  i 
with  respect  to  processor  j. 

•  Task  exclusive  matrix:  Defines  mutually  exclusive  tasks,  and  ex- 
ptessed  aiaimxm  matrix.  X{j  ■  0  means  no  constraint  between 
task  i  and  task  j.  Xij  ■  1  means  task  i  and  task  j  can  not  be  assigned 
to  the  same  processor. 

3.  The  cost  function  is  formulated.  It  depends  on  the  following  parameters: 

•  Task  coupling  factors  cy,*:  number  of  data  units  traaafered  from  task 
j  to  task  k. 

e  inter-processor  distance  d,  ,p:  the  cost  of  a  transfer  of  one  data  unit 
from  q  to  p. 

e  tasks  quadratic  assignment  formulation:  (Xi<p  *  1)  means  task  j 
assigned  to  processor  p. 

2.4  Graph  Based  Structured  Design  Method 

A  graph  based  design  method  uses  techniques  taken  from  graph  theory  in  order 
to  analyse  and  construct  the  system.  The  main  difference  between  this  method 
to  the  structured  method  is  that  all  data  dependencies  are  explicitly  expressed. 
This  method  is  superior  to  the  structured  method  in  its  capability  to  identify 
operations  on  data  which  are  common  to  many  timing  constraints. 

2.4.X  Graph  Based  Theoretical  Model 

Mok  (in  (20))  provides  a  theoretical  examination  of  the  graph  based  d—igi. 
approach,  and  the  problems  which  arise  when  applying  a  scheduling  algorithm 
baaed  on  this  model. 

Modal  Description 

A  graph  based  model  M  is  an  ordered  pair  (G,  T),  where  G  is  the  communication 
graph  of  the  system,  and  T  is  a  set  of  timing  constraints  that  satisfies  T  = 
{Tp}u{Ts}.  The  subeets  Tp  and  Ta  are  the  periodic  and  asynchronous  (sporadic) 
constraints  respectively.  The  communication  graph  G  =  (V,  E,  Wv)  is  a  di¬ 
graph  which  may  contain  cycles,  in  which  V  is  a  set  of  vertices,  E  is  a  set  of 
edges  (directed  arcs),  and  W v  denotes  a  function  that  assigns  a  non-negative 
weight  to  each  node  in  V .  Each  timing  constraint  in  T  is  represented  by  a 
triple  (C,p,d),  where  C  is  a  timing  constraint  acyclic  graph  (compatible  with 
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O),  and  p ,d  wpHMt  the  periodic  ud  deadline  conetraiate  respectively.  In  the 
eaee  of  asynchronous  (sporadic)  coaetraint,  p  repreeenta  the  maximal  occnrance 
frequency  allowed. 

The  timing  constrain te  graph  expresses  the  precedence  relations  between 
cosnpntataoaal  events  that  meat  be  kept  in  order  to  satisfy  the  timing  con¬ 
straints.  Execration  of  a  functional  element  is  denoted  by  a  node,  and  data 
liansmUted  in  the  communication  graph  (G)  by  a  directed  arc.  The  computa¬ 
tion  time  of  a  constraint  (C,  p,  J)  is  obtained  by  summing  the  weights  of 

aU  the  nodes  in  C.  If  ( C,p ,  d)  is  activated  at  time  t,  then  C  most  be  executed 
at  (t,t  +  d). 

C  b  said  to  be  executed  in  a  time  interval  L,  if  a  subset  S  of  the  (multi)set 
of  the  functional  dements  of  C  was  executed  in  L  and  forma  a  partial  order 
such  that: 

1.  There  exists  a  bijective  mapping  between  the  functional  elements  in  5  and 

C. 

2.  Under  this  mapping  the  partial  order  of  S  is  consistent  with  the  acyclic 
graph  C. 

S.  If  the  functional  elements  ere  distributed,  and  there  exists  an  edge  u  — *  v, 
then  an  execution  of  C  must  include  a  transmission  of  the  latest  output 
of  m  to  v,  before  v  fa  executed  in  L. 

Pipelined  Order  Requirement 
A  pipelined  order  fa  interpreted  by  Mok  as: 

1.  If  two  executions  of  a  functional  dement  have  two  distinct  start-times, 
then  the  one  with  the  earliest  start-time  must  abo  finish  first. 

2.  No  massage-overtaking  (desequencing)  fa  allowed. 

Defining  e  as  the  execution  time  of  C,  allows  mapping  T  *  (C,  p,  d)  to  T*  » 
(c,  p,  d).  Then,  creating  a  monitor  for  each  functional  element  of  C  that  occurs 
in  more  than  on a  timing  constraint,  allows  imposing  the  pipelined  order  require¬ 
ment.  Decomposition  of  each  functional  dement  into  subelements,  whose  sum 
of  execution  times  fa  approximately  the  same  as  those  of  the  functional  element, 
fa  aa  a  matter  of  fact  software  pipelining.  This  pipelining  improves  ths  efficiency 
by  taking  advantage  of  operations  that  are  common  to  many  timing  constraints. 

Latency  and  Static  Scheduling 

Mok  defines  some  metrics  that  are  needed  for  defining  and  analysing  a  static 
scheduler.  First,  aa  execution  trues  of  a  processor  is  defined  as  a  mapping 
from  the  non-negative  numbers  to  the  set  of  all  the  functional  dements  in  G 
and  the  idle.  We  denote  this  mapping  as  F.  Recall  that  the  graph  based 


21 


V 


model  M  =  (G,  T).  For  example:  F( t)  =  u  if  the  functional  element  u  in  G  is 
executed  in  the  time  interval  (*,  i  +  1),  and  F(i)  =idle  if  the  processor  idles  in 
(t,»  +  1).  Second,  an  execution  trace  is  said  to  have  latency  k  with  respect  to 
a  timing  constraint,  if  the  execution  trace  contains  an  execution  of  the  timing 
constraint  in  any  time  interval  of  length  greater  or  equal  to  k  time  units.  A 
static  schedule  is  defined  as  a  finite  list  Y  of  symbols  from  the  set  of  vertices 
of  G  and  the  idle.  The  latency  of  a  static  schedule  is  defined  with  respect  to  a 
round-robin  generated  schedule.  Y  has  a  latency  of  k  time  units  with  respect 
to  the  constraint  (G,  p,  d)  IFF  the  execution  trace  generated  by  a  round-robin 
scheduler,  repeating  Y  ad  infinitum,  has  a  latency  of  Jb.  In  order  that  a  static 
scheduler  would  be  feasible  with  respect  to  a  set  of  asynchronous  constraints 
Ta,  it  should  have  a  latency  d  with  respect  to  every  [C,p,  d)  in  T„.  Mok  proves 
the  following  properties  for  a  graph  based  model  (G,  T): 

•  The  existence  of  a  feasible  static  schedule  with  respect  to  T  in  the  cases 
where  a  latency  d  exists  for  every  (G,  p,  d)  in  T. 

•  Proving  the  existence  of  a  feasible  static  schedules  when  the  above  re¬ 
quirement  is  not  satisfied,  is  NP  hard  even  for  relatively  simple  cases. 
Only  application  of  additional  constraints  on  relations  between  computa¬ 
tion  times  and  deadlines  allows  proving  the  existence  of  a  feasible  static 
schedule. 

2.4.2  Data  and  Control  Flow  Graphs 

A  graph  modeling  technique  which  is  commonly  used  is  the  Data  Flow  Graph 
[22],  and  its  description  and  usage  possibilities  are  give  below.A  bi-digraph  is 
used  to  model  the  system.  A  control  flow  graph  describes  the  structural  behavior 
of  the  program  and  the  control  flow  daring  execution,  while  a  data  flow  graph 
(corresponding  to  each  execution  sequence)  describes  the  data  behavior  during 
this  execution. 

Data  Flow  Graph  Model  Description 

In  the  control  graph:  the  vertices  represent  control  points,  and  the  directed 
arcs  represent  actions  or  control  transitions.  In  the  data  flow  graph:  there  are 
two  types  of  vertices  •  data  items  and  operations.  The  vertices  are  connected 
by  directed  arcs  describing  the  data  flow.  A  data  flow  graph  corresponds  to 
an  execution  sequence  S  =  (a* ,..,a„)  in  the  control  flow  graph,  by  attaching 
to  each  arc  a*  a  mapping  of  input  variables  into  output  variables 

(Vi, ..,  Ym).  This  functional  relation  is  the  vertex  of  type  “operation*  which 
appears  in  the  graph.  The  graph,  which  may  be  very  large  in  case  of  a  complex 
program,  may  be  reduced  by  means  of  abstraction  levels,  merging  data  items 
to  vectors,  and  sequential  actions  into  control  segments. 
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Usage  of  Data  Flow  Graph 

This  graph  may  be  used  to  both  demonstrate  structural  properties  and  verify 
some  performance  ones. 

•  Independent  data  items  may  be  detected,  and  point  to  the  distributed 
implementation  that  require*  less  communication  traffic.  The  problem 
becomes  a  partitioning  problem  which  requires  that  the  number  of  arc- 
cats  is  minimised. 

•  Each  execution  sequence  with  its  corresponding  data  flow  graph  encoun¬ 
ters  all  the  information  needed  for  numerical  error-bound  analysis. 

2.5  Operational  and  Event  Based  Design  Meth¬ 
ods 

An  event  based  design  method  describes  the  system  as  a  mechanism  which 
responds  to  events  fed  to  it  from  the  external  environment.  It  was  already 
mentioned  in  this  review  that  a  real  time  system  has  high  dependency  on  the 
implementation  of  the  design.  The  main  difference  between  the  event  based 
approaches  is  to  what  extent  the  design  is  separated  from  the  implementation. 

2.5.1  Event  Based  Model 

Event  based  model  of  a  system  [9],  separates  the  systems ’s  properties  into  two 
major  categories:  behavior  which  mainly  concerns  the  external  view  of  the  sys¬ 
tem,  and  structure  which  reflects  the  internal  view  of  the  system.  Proving  the 
correctness  of  a  system  is  translated  to  a  consistency  check  between  the  behavior 
and  the  structure.  Orthogonality  between  properties  allows  verification  of  each 
independently,  and  thereby  avoids  “exponential  state  explosion*  when  coming 
to  derive  test  sets. 

Description 

The  model  is  constructed  from  events  and  their  relations: 

1.  An  event  is  an  instantaneous  (takes  sero  time)  atomic  (happens  completely 
or  not  at  all)  state  transition  in  the  system’s  computation  history. 

2.  Time  ordering  of  events  is  achieved  with  the  precede  ( — ♦)  relation,  which 
is  a  partial  ordering  found  also  in  [24],  Event  el  precede  event  e2(el  — * 
e2)  if: 

*  el,  e2  are  events  at  the  same  process  (an  autonomous  computation 
node,  having  its  own  local  dock)  AND  el  comes  before  e2,  OR 
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•  el,e2  an  events  at  different  processes,  AND  el  is  a  tend  message 
event,  AND  e2  is  s  receive  event  of  the  very  same  message. 

This  partial  ordering  e  ns  ores  that  el  — *  e2  implies  that  el  happens  before 
e2  by  any  messnre  of  time.  (It  is  not  IFF!).  The  ordering  is  transitive, 
irreflexive  and  anti-symmetric. 

3.  Causality  ordering  is  achieved  with  the  enable  (  =>  )  relation,  which  is 
also  a  partial  ordering,  and  is  defined  as  follows: 

•  Event  el  enables  event  e2(el  =>  e2)  IFF  the  existence  of  event  el 
will  cause  occurance  of  event  e2  in  the  future. 

This  ordering  is  also  transitive,  irreflexive  and  anti-symmetric. 

4.  Domains  are  used  to  ease  the  specification  procedures.  Three  of  them  are 
used  to  classify  the  events:  the  system,  the  environment,  and  interface 
ports.  The  main  idea  is  to  construct  the  specifications  in  a  scheme,  where 
the  system  and  its  environment  interact  with  each  other  using  message 
communications  that  are  exchanged  via  uni-directional  interface  ports. 
In-ports  are  used  to  enter  messages  from  the  environment  to  the  system, 
and  out-ports  are  used  for  the  opposite  direction.  In  every  port  a  total 
ordering  of  events  is  imposed  by  tttigning  a  distinct  ordinal  number  to 
each  interface  event. 

2.5.2  Design  with  Event  Based  Approach 

The  system  specification  is  entered  as  a  set  of  axioms,  applying  top  down  ap¬ 
proach.  The  behavior  specification  is  done  using  EBS  language,  which  is  based 
on  the  event  concept  and  first  order  logic.  The  behavior  (external  view)  is  spec¬ 
ified  first,  and  then  it  is  decomposed  into  a  design  structure  (i.e.  the  internal 
view).  Finally,  the  model  is  verified  with  a  consistency  proof,  to  assure  that  the 
structure  satisfies  the  behavior  requirements.  The  decomposition  process  uses 
three  construct  types  to  describe  the  design  structure:  the  sub-system,  the  link, 
and  the  interface-definition.  The  objective  is  to  decompose  the  design  structure 
such  that  sub-systems  communicate  with  each  other  through  uni-directional 
links,  and  the  communication  with  the  environment  is  done  through  the  inter¬ 
face  definitions.  The  constructs  are  specified  as  follows: 

A  sub-system:  A  set  of  events,  a  subset  of  the  system  events  set.  The  com¬ 
putation  is  defined  by  the  behavior  specification. 

A  link:  A  connection  between  an  out-port  of  the  subsystem  to  an  in-port  of  an¬ 
other  subsystem;  as  in  “connect  (X,Y)==Z*,  where  Z  is  a  link  connecting 
out-port  X  to  in-port  Y. 


Aa  butexfaeo-def:  A  definition  of  a tub-system' i  port  u  n  ayatem'a  port;  as  in 
*X=*=Y*  where  »  sub-system’s  port  X  ia  the  system's  port  Y.  Both  porta 
ahoold  hare  the  same  direction. 

An  example  of  a  design  struct  ore  can  be: 

Def  System  S(I :  in  —  port;  0  :  out  —  port)\ 

Structure 

Sab  system  SS(II :  t«  —  port;  00  :  out  —  port)\ 

Behavior 

end  Behavior; 

Sab-system  ... 

Network 

eonneet(X,  Y)  **  Z ; 
end  Network; 

Interface 

H— I; 

end  Interface; 
end  Structure; 
end  System; 


2.5.3  Operational  Approach 

The  PAIS  Ley  project  uses  a  new  approach  in  real  time  systems  design,  in  which 
the  idea  of  an  implementation  dependency  is  expressed  in  a  strategy  called 
operations/  approach  [35]. 

Principle 

The  main  idea  is  that  external  behavior  and  internal  stractore  may  interleave. 
In  order  to  maintain  generality,  the  operational  approach  separates  the  problem- 
oriented  stractore  of  the  operational  specifications  from  pure  implementation 
considerations.  The  operational  specifications  themselves  are  written  in  an  op¬ 
erational  specification  language,  which  is  executable  and  prevents  ambiguities. 
The  execatability  feature  of  the  specification  provides  a  tool  for  early  results  ex¬ 
amination,  and  can  be  regarded  as  a  functional  simulator  that  corresponds  to  the 
specifications  constraints.  Automated  translation  (from  specification  statement 
to  an  implementation  code)  is  highly  feasible,  since  problem-oriented  internal 
constraints  are  taken  into  account.  This  transformational  implementation  would 
therefore  guarantee  correctness  of  the  produced  code.  P.  Zave  compares  the  op¬ 
erational  approach  with  the  conventional  approach  in  [35].  A  summary  of  this 
comparison  is  given  below. 
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Operational  Varans  Conventional  Design  Approach 

•  Advantages  of  the  conventional  approach: 

1.  The  informal  spedicatioa,  written  in  English  or  another  nataral  lan¬ 
guage,  can  be  aaderstood  bjr  everyone. 

2.  Organisational  beaeftts  (like  miUttonoi)  are  easily  obtained. 

•  Advantages  of  the  operational  approach: 

1.  The  specifications  are  formal  and  aon-amhigaons. 

2.  A  rapid  prototyping  is  available  automatically. 

3.  Verification  is  easy  das  to  fixed  transformational  implementation. 

4.  The  realisation  phase  is  highly  aatomatable. 

5.  The  conflict  between  efficiency  aspects  and  maintenance  aspects  is  a 
major  concern. 

e  Weaknesses  of  the  conventional  approach: 

1.  Although  known  from  the  very  beginning,  realisation  constraints  are 
ignored  throughout  the  design  phase,  furthermore,  the  effects  of  the 
system  structure  on  the  behavioral  properties  are  ignored. 

2.  The  top-down  approach  imposes  dittculties  in  specifying  blocks  whose 
content  is  ignored,  and  increases  the  risks  and  difficulties  in  decom¬ 
posing  sub-systems. 

e  Weaknesses  of  the  operational  approach: 

1.  A  danger  of  too-eariy  design  decisions  is  presented. 

2.  Executing  the  specifications  is  probable  not  to  have  any  performance 
properties. 

3.  The  transformational  implementation  contains  all  the  realisation  con¬ 
straints  and  therefore  is  not  unique  but  rather  implementation  depen¬ 
dent.  Each  individual  transformation  should  therefore  be  carefully 
proved,  prior  to  relying  on  it  as  assurance  of  the  realisation  correct- 

2.6  Finite  State  Automata  Modeling 

A  large  variety  of  finite-state  machines  are  need  to  specify  and  analyse  con¬ 
current  processes  (e.g.  Petri  nets,  SPECIAL,  etc.).  Petri  sets  [31]  are  found 
exceptionally  suitable  for  cases  that  involve  designing  and  modeling  of  systems 
in  which  concurrent  processing  considerations  and  dynamic  ssqmential  depen¬ 
dencies  exist.  The  major  characteristics  of  Petri  nets,  in  comparison  to  other 
models,  art: 
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a.t.1  Pstri  N«ta  DtAmitioti 

▲  Pnri  m*  m  [ll|  m  •  l«i  tapia  <  P,  T,  Pn,  P—t,  M«  >,  wtw 

•  Pm  (r i.  -.P»)  *  Ml  «l  yfawr 

•  T  ■  {tt, ...  U>  4  fariH  Ml  rf  tWMlWM. 

•  Fr«  is  »  Mappiag  Tx  P  -*  M  * 

•  PM  is  •  Mfftai  PxT  —  M . 

•  Mi  fa  ifc*  failfal  Mkh|  «f  tfca  ad.  Tlw  mmMbc  ii  mmUmI  m  lohnt 


•  It 


S.  k  ii  complete 
all  tbo  tokaao  an 


i  Ira,  a  cm  of  a  partial  ftrtaf  ia  wbicb  aot 
aot  all  Ikt  tobeao  an  placed,  dooa  aot  occur. 


Ft*  aot,  oaly  oao  vfl  An.  Iclactioa  of  Um  ooo  tlu it  flna  ia  carried  oat  arbitrarily. 


14.3  Tuk  SyBehroBlutioo  with  Petri  Net* 

A  took  cm  bo  daAaad  to  bam  tbno  otatea  with  reopect  to  a  eyadurocuaiay 


1.  k  cm  bo  idle  or  iadiffereat  to  tbo  ayaebrooista*  mochaaicn 

2.  k  caa  bo  eolMf  at  a  oyaebrooioatioo  poiat. 

9.  k  caa  bo  octree,  or  aria*  a  reooarco  after  ayaebroaiaatioa. 

Wbaa  awdolia*  a  talk  with  a  Petri  aot,  tbo  traaottioa  dopicta  tbo  active  part 
of  tbo  took.  Tbta  papoty  ia  vary  bad  Car  doacribiB*  tlmia*  proportioa,  aiaco 

active,  ita  at  ate  ia  the  aot  ia  aadoiaod.  Tbo  coadkioaa  far  catena*  tbo  active 
•tote  an  repnonaod  by  the  pUcea. 

^ranplt  (11)>  Wboa  took  TyPIfan  2.1)  tonaiaatoa,  taaka  7*  aad  T%  an 

Yet,  if  a  taak  baa  aiakipli  write,  a  "place”  far  tbo  active  part  of  tbo  took 
■aot  bo  preiwtil,  aa  far  T«  ia  Ficon  2.2. 


la  boom  caoee  at  two  procooooo  abariag  tbo  aaaao  took,  partial  order  ia  eafaaeat, 
bat  wboa  notaal  oadaatoa  ia  iavotvad,  total  order  ia  a  mart.  Tbo  aotatioa  for 
total  aad  partial  order,  ariaf  a  Petri  aot  model,  ia  empbaaioed  ia  Pifem  2.9. 

1.  Total  order:  px  caaooa  a  rtroctoral  coalkt  botwooa  aad  t3.  Tbie  coo- 
fact  ia  effective  ia  tbo  caoo  that  pi,  pi  aad  p»  an  otarked  by  oao  tokoa 
eoeb.  Wboa  <i  aad  ty  an  execated  oa  diffenat  proceoeon,  px  repr  people  a 
ayaebroaiaatioa  variable,  wbkk  mart  bo  protected  by  a  mataal  oaclaaioa 

2.  Partial  Order:  Wbaa  a  aood  arioeo  for  a  ayaebroaiaatioa  variable  wbicb 
implomeata  a  partial  order,  it  caa  bo  repnocalcd  by  a  place  wbicb  baa  a 
riagie  oetpet-traaottioe  aad  mahipie  iapat-traaoitioao.  Ia  Pi«are  2.9  tbe 
place  p«  npnoeaU  each  a  variable.  Both  ts  aad  t«  caa  iacreaoe  ita  valae 
(by  Iriac  tokoao  iato  p«),  bat  oaly  oao  caa  decnaoe  ito  valae  (ia  tbie  can 
nprmaated  by  t*). 
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Fifars  2.3:  TbtaJ  sad  partial  ardsr  coaikts. 


MvM-i 


aaianaaiSBt  is  by  ssisg  priailrw  as  — ad  sad  sal  Apptjriag  this  approach 
dbscUy  froa  tbs  M,  iriss  s  ▼ioUUoa  of  tkt  tr ■— itioa  trisg  iadi*tfbi%  rmls. 
This  pwMi  csa  bs  sotosd  ({11]}  by  gaibariag  Um  wbots  syacbroaisatioa  oMeb* 
saiMB  iato  sas  spsdic  task.  Each  at  Um  othsr  tasks  that  sssds  to  syacbnmiss 
visb  sastbsr,  ssads  a  syacbr— isatioa  wg— t  (accosapaatsd  by  tbs  idsatity  o t 
Um  traasMaa  that  bas  to  bs  ftrsd)  to  tbs  ■yacbroaisar-task  Tbs  sjracbroaissr 
coastdsn  tbs  ast  as  a  databass,  sad  reacts  to  rscsmag  a  rsqasst  by  ssarcbiag 
tbs  appropriali  Iriaartioa,  sad  wbsa  ftadiag  aa  saablsd  oas  by  coatrolliag  tbs 
ftrtag  aasratioa.  This  caatnhssd  solattoa  bas  scmrs  adnataga: 
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Plgw*  2.4:  Prod«car/coa 

mumt  Mitomwwr  mo4d 

•  A  iMalvinr  of  tho  mi  is  obtaiaod 

•  The  ydwdwrtio  proem  a  derind  ‘dboctly*  boa  tb*  eat. 

•  Chaapao  (oka  <mU)  an  eerily  fast,  me*  ill  Um  proem  port*  on 
located  is  see  apodric  piece. 


faaplmoatiaf  lW  eyachnaiaatioe  aaochaaim  ie  tifaml  ia  Um  com  whan  par* 
rial  order  iooalcim,  boa  the  coco  when*  total  ardor  ieaocoaoaiy.  Ia  (11)  Um 
dMmarte  on  doacribod  ao  follows. 


Partial  Order  la  adbhati  The  axamplo  p*w  for  Um  riaglo-prodacor  riagl*- 
eomnaor  can  eh  owe  dearly  Uut  oach  of  the  tnaritioaa  ts  aad  t«  caa  be 
epril  ialo  two  ports.  The  aptiitiag  is  described  ia  Pigare  2.5. 

Whea  epachroaiaor  1  Ine  4,  it  aeade  a  aMosaga  to  oyachroaion  2,  which 

to  4,  aad  tho  raalt  ia  of  a  ana  reatrolbeil  oyachroaiaarioa  Merbeaien  ia 
the  can  of  partial  ardor. 


Tho 


to  the  two  prodoc- 


m  prehlm  (gtne  ia  Figan  2.4)  ie  dneribed  ia  Figan  2.6 :  <!,/*„,  t,  aad 
*i>^ew>4  Much  roprasaat  tho  regnal  -  wariiag  -  aatboriaatioa)  anot  be 
dapriceted  ia  the  global  oyachroaieer  ao  it  caa  dacido  apoo  aatboriaatioa. 


i),  which  ie 


ncoend  by  tho  global  ayachroaioer  ao  a  raqaaot  for  Iriag  <u  Whoa  the 
global  qrachroaioar  Ins  t*  (ao ad*  aa  ‘accept'  nmofo  to  oyachroaiaar» 
1),  it  io  near* ad  by  ayachroaioer  1  as  a  nqaoat  for  ftriag  t*.  The  mm 
acboan  io  appiaa  to  ayachnaioan  2  aad  J.  Hoaco,  a  ample  eweawakr 
rioa  ia  aaWcim  for  iaipiaaMBtiag  the  nmtgot  raqatnd  for  the  ayaebro- 


J#A  Tima  Augmented  Patri  Nats 

Ao  noatioaod  briar  a,  tho  Patri  aat  rlaoriral  Model  traaaatioao  an  Ind  ia  a  aoa- 
dalvniairiii  wop,  aad  do  aot  captor*  tho  aotioa  of  tin*.  Ia  ardor  to  odjast 
rib  Madoriag  Method  to  real  tine  program,  varioae  atodllcaiioaa  wan  applied 
to  the  rlaoriral  Modal.  Aa  approach  which  t taiga i  the  execatioa  to  troaeitioaa 
which  an  Uoawaaaotatod  (2t|,  ia  daecribad  ia  chapter  5.  Tbs  problem  with  thie 
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Fienre  2.6:  Distributed  total  order  synchronisation. 


approach  is  that  the  transitions’  ititonUmoni  nature  is  not  satisfied  completely 
withoat  “inhibit*  features.  Another  approach  is  to  assign  stochastic  nature  to 
the  firing.  This  approach  is  very  good  for  average  performance-analysis,  and 
some  methods  are  mentioned  in  chapter  4  ([27,3,7]).  The  stochastic  approach, 
which  is  very  useful  for  verification,  does  not  address  important  temporal  prop¬ 
erties  which  are  crucially  important  in  the  design  phase  (e.g.  scheduling,  safe¬ 
ness  with  presence  of  time,  etc.).  The  next  paragraphs  review  a  method  [10] 
ia  which  the  latter  issues  are  addressed  by  an  augmented  Petri  net  model,  in 
which  timing  properties  are  assigned  to  places  in  the  graph. 

The  Augmentation 

Unlike  the  approaches  mentioned  above,  in  Coolahan  and  Rouaopouloe  aug¬ 
mentation  of  a  classical  Petri  net  [10],  processing  is  represented  by  places,  and 
instantaneous  transitions  represent  start  and  stop  of  a  process.  Hence,  a  non¬ 
negative  time  value  is  assigned  to  each  place;  if  the  place  is  a  "condition*  then 
the  value  is  sero,  if  it  is  a  process  then  the  value  equals  the  execution  time  of  this 
process.  A  token  is  ready  to  enable  an  output  transition  of  the  place  it  occupies, 
after  residing  on  this  place  for  the  assigned  time.  If  one  transition  is  enabled 
when  the  token  becomes  ready,  then  this  transition  fires  immediately.  If  more 
than  one  transition  is  enabled,  then  a  non-deterministic  selection  occurs,  and 
only  one  of  the  transitions  fires  immediately,  while  the  others  become  disabled. 

Tima  Drhran  System  Model 

Pour  set  veined  function*  define  the  relations  between  nodes  of  the  network  (i.e. 
the  directed  arcs): 

•  /<((<):  Transition  input-function,  mapping  transition  U  to  the  set  of  places 
front  which  there  exist  arcs  to  t<. 

e  0|(tj):  Transition  output-function,  mapping  transition  t,  to  the  set  of 
places  to  which  there  exist  arcs  from  t*. 

e  similarly,  place  input-function  (/P(p<))  and  place  output-function  (Op(pi)) 
are  defined. 

The  cardinality  at  the  above  sets  is  denoted  by  |..|. 

The  master  timing  machine,  which  triggers  the  network  to  be  activated  by 
a  marking  sequence,  consists  of  a  place  denoted  as  p\,  connected  to  a  transition 
ti  through  a  loop.  The  following  properties  hold  for  this  machine,  called  the 
Driuinf  Cycle: 

•  The  initial  marking  of  pi  (mi  *  1)  reproduces  itself  with  a  fix  period  7\. 

•  A(*i)  *  Pi- 


•  Pi  €  Ot(h),  and  |0«(ti)|  >  1. 

•  Ip(Pi)  =  Op(Pi)  =  {«i}- 

The  net  is  constructed  in  steps  that  are  described  below.  Throughout  the  con¬ 
struction,  it  is  guaranteed  that  a  path,  originated  at  the  driving  cycle,  reaches 
the  places  or  transitions  which  are  currently  added,  to  ensure  reachability  of 
these  nodes  (Le.  a  liveness  potential).  Yet,  the  safeness  property  of  the  classical 
Petri  net  is  affected  by  the  reproduction  property  of  the  driving  cycle,  since  no 
assurance  is  given  to  guarantee  a  bounded  number  of  tokens  in  the  net.  This 
problem  is  solved  by  the  time  considerations,  which  enforce  a  bounded  firing 
rate  on  the  driving  cycle. 

Concept  of  Relative  Firing  Frequency 

Two  important  properties  are  assigned  to  places  and  transitions  in  the  net: 

MRFF :  (Max  Relative  Firing  frequency)  The  number  of  times  a  transition 
fires,  with  respect  to  each  firing  interval  of  the  driving  cycle,  if  all  the  de¬ 
cisions  (selections  of  enabled  transitions  to  fire)  between  the  driving  cycle 
and  that  transition  are  made  *in  favor”  3  of  the  path  to  that  transition. 

MTIAT :  (Min  Token  Inter-Arrival  Time)  The  shortest  possible  time  interval 
between  two  consecutive  arrivals  of  tokens  to  the  relevant  place. 

An  important  relation  is  established  by  the  above  definitions:  If  U  is  an 
input  transition  to  a  place  py,  and  T\  is  the  driving  cycle  period,  then 

MTIAT[pj)  =  Ti/MRFF(U). 

Sub-classes  of  Time  Driven  Systems 

Four  sub-classes  serve  as  construction  units  in  the  model  presented  in  [10]: 

1.  Asynchronous  Systems:  For  every  place  Pi  and  transition  ty  the  following 
hold: 


•  I4(P<)I  =  |G«(ty)|  =  1- 

•  \Op(pi) |  >  1. 

Asynchronous  systems  are  constrained  by  the  following: 

1.  Execution  time  of  any  process  (i.e.  place)  cannot  exceed  the  MTIAT 
of  this  place. 


*If  a  decision  is  pre-determined,  then  the  ratio  in  which  it  is  taken  in  favor  of  a  specific  path 
is  given.  If  a  decision  is  data  dependent,  then  only  assumptions  or  upper  and  lower  bounds 
can  be  expressed. 
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Figure  2.7:  Asynchronous  sub-system. 

2.  The  cumulative  execution  time  of  any  path  cannot  exceed  any  separately- 
stated  path  execution-time  requirement  {path  latency  requirement). 

An  example  of  this  class  is  illustrated  in  Figure  2.7. 

2.  Synchronised  Systems:  In  addition  to  asynchronous  sub-systems,  this 
sub-class  includes  parallel-path  constructions,  which  consist  of: 

•  T:  a  set  of  transitions  {(»,  t/,  Tp),  an  initial  transition,  a  final  tran¬ 
sition,  and  a  set  of  sero  or  more  path  transitions. 

•  P:  a  set  of  path  places  {pp}. 

PuTp  contains  n  (two  or  more)  disjoint  sub-sets,  each  representing  a  path 
from  U  to  tf.  The  following  properties  hold  for  the  parallel  constructs:  4 

1.  For  U  (the  initial  transition): 

•  /.fr)  nP  =  {>. 

•  |Ot(t.)  n  P\  =  n. 

4n  denotes  Mt  intersection.  u  denotes  set  union.  C  denotes  contained  relationship. 
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Figure  2.8:  Synchronised  tub-system. 

2.  For  tf  (the  final  transition): 

•  /*(£/)  £  P.ond|/t(t/)l  =  n. 

e  o,(t/)n /»  =  {}. 

3.  For  each  tp  (path  transition  •  if  any): 

•  | It{tp)  n  P\  >  1. 

•  \Ot(tp)  n  P\  >  1. 

4.  For  each  pp  (path  place)  in  P: 

•  I4(Pp)I  =  1  and  Ip{pp)  C  T. 

•  I°p(Pp)I  =  1  and  Op(pp)  C  T. 

An  example  of  this  sub-class  is  illustrated  in  Figure  2.8. 

An  additional  timing  constraint  is  imposed  on  the  synchronised  sub-systems: 

•  For  any  set  of  parallel  paths,  delimited  by  t,  and  tf.  the  sum  of 
execution  and  waiting  times  that  a  token  spends  at  the  final  place 
(of  any  of  the  paths),  must  not  exceed  the  MTIAT  of  that  place. 
The  waiting  time  at  the  final  place  of  a  specific  path  is  the  difference 
between  the  greatest  total-path-time  of  the  set  of  paths,  and  the 
total-path-time  of  this  specific  path. 

S.  Independent-cycle  Systems:  In  addition  to  synchronised  sub-systems, 
this  sub-class  includes  cycle  constructions,  which  consist  of: 
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Figure  2.9:  Independent-cycle  eub-eyatem. 

•  T:  a  set  of  transition*  (t*,  Tp),  an  initial  transition,  and  a  set  of  sero 
or  more  path  transitions. 

e  P:  a  set  of  path  places  {pp}. 

PUT  represents  a  cyclic  path  from  U  to  U-  The  input-places  to  the  initial 
transition,  are  one  internal  to  the  cycle,  denoted  as  p /,  and  one  external 
to  the  cycle,  denoted  as  p«  and  called  the  entry-place.  The  latter  has  only 
one  input  arc,  and  one  output  arc  which  feeds  U-  An  independent  cycle  is 
characterised  by  the  following  properties: 

1.  For  ti  (the  initial  transition): 

•  |/,(t,)|  -2  and  |J,(tO  nP|«l. 

•  |Ot(ti)nP|*  l. 

2.  For  each  tp  (path  transition  -  if  any): 

•  ~  1  and  h{tp)  C  P. 

•  |0«(t,)|  -  1. 

3.  For  each  pp  (path  place)  in  P: 

•  |Jp(Pp)l  =  1  and  Jp(pp)  C  T. 

•  \Op[pP)\  =  1  and  Op(pp)  C  T. 

An  example  of  this  sub-class  is  illustrated  in  Figure  2.9. 
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An  additional  timing  requirement  (to  thoaa  of  the  aynchronised  systems) 
is  imposed  on  the  independent  cycle: 

•  For  any  independent  cycle,  the  cycle  execution-time  (from  t,  back  to 
t<)  most  not  exceed  the  MTIAT  of  the  entry  place. 

4.  Shared  resource  Systems:  In  addition  to  all  the  tab-classes  described  so 
for,  this  sub-class  permits  cyclee-overlap  to  model  reeource  sharing.  The 
cycles  which  overlap  have  input  transitions  whose  firing  rates  are  equal  un¬ 
der  all  conditions,  and  their  final  places  are  replaced  by  a  shared  resource. 
This  construction  consists  of: 

•  Tp:  a  set  of  path  transitions  {tp}. 

•  P:  a  set  of  path  places  { Pi,p/,Pp }. 

The  following  properties  characterise  the  »h and- reeource  construct: 

1.  For  jn  (the  initial  place): 

•  |/P(pi)|  =  n,  one  input  transition  from  each  of  the  n  cycles, 
e  Upijtp/  then  |Op(p<)|  *  1  and  Op(p,)  {£  T. 

2.  For  pf  (the  final  place): 

e  \Op(pf)\  »  n,  each  output  transition  being  an  input  transition 
to  one  of  the  cycles. 

•  The  initial  marking  is  one  ready  token. 

•  I tPi^Pt  l*r(P/)l  =  1  »nd  /p(p/)  £  T. 

3.  For  each  pp  (path  place  -  if  any)  in  P: 

•  \Ip(Pp)\  =  1  Ip{pP)  C  T. 

•  l°r(Pr)l  *  1  Opipr)  <=■  T- 

4.  For  each  tp  (path  transition): 

•  Ii(tp)  C  P. 

•  Ot(tp)  c  P. 

An  example  of  this  sub-class  is  illustrated  in  Figure  2.10.  The  initial 
marking  in  p/  is  the  semaphore  that  controls  the  mutual-exclusion  of  the 
resource. 

The  constraint  that  was  mentioned  while  introducing  this  construct,  may 
be  applied  as  a  restriction  to  the  construction  process;  ensuring  that  all 
firing  frequencies  of  all  the  input  transitions  to  the  entry-places  are  equal 
must  be  applied  before  continuing  the  construction.  Additional  timing 
constraint  for  the  shared-resource  constructs  is 

T*i  +  Elksl.i tj{Tck)  ^ 
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Figure  2.10:  Shared-resource  nlHyiMn. 

where: 

•  r„,  -  Execution  time  of  entry-place  p«y. 

e  T«*  -  (or  T0y)  Execution  tint  of  all  places  ia  the  cycle,  wkick  ara 
activated  aa  a  coaaaqaaaca  of  tka  iapat  provided  by  p«*  (or  p,y). 

•  T4  -  Tbe  MT1AT  at  aacb  of  the  i»  aatry  places. 

Tba  above  constraint  ensures  that  p, y  ia  aafa  ia  presence  of  time. 

Nat  Cone  traction  Methodology 

The  construction  of  the  augmented  Petri  net,  is  represented  in  (10)  in  an  al¬ 
gorithmic  way,  in  which  all  the  above  constraints  are  taken  into  consideration. 
The  method  consists  of  the  following  steps: 

1.  Construct  a  driving  cycle  (pi  -  Tj, ty). 

2.  Add  places  to  the  driving  cycle’s  transition  (ty)  as  the  system  to  be  mod¬ 
eled  requires,  such  that  each  of  the  added  places  has: 

e  a  single  input  arc, 
e  a  finite  execution  time. 

3.  To  each  of  the  places  which  does  not  have  an  output  so  far,  one  or  more 
of  the  following  constructs  are  added  as  an  output  (according  to  what  the 
system  to  be  modeled  requires): 

e  A  single  transition  with  exactly  one  input  arc. 


•  A  MiplKi  parallel  syuckroaiaed-path  coUwrt. 

•  A  trenail  inn  with  multiple  iiptto,  which  completes  a  synchronised- 
patk  whaa  added  to  th*  sub- eat  tktt  is  already  caaKncttd. 

•  Aa  independent  cycle  contract. 

•  A  cycle  which  forma  a  part  of  a  shared-resource  coaetract,  guaran¬ 
teeing  tktt  all  autry-placa*  ira  at  Um  aaae  fraqaeacy. 

4.  Add  oatpat  plane  (ae  ia  step  2)  to  each  transition  wkkk  kaa  ao  output- 
place  ao  far. 

5.  Repeat  etepe  (3-4]  aatil  tke  model  ia  complete. 

Dwrfoetkm  off  Max  Relative  Firing  Frequency 

Tke  firiag-frequeaciae  of  traaeitioaa,  rrprsaesd  ia  tenaa  of  tke  freqaeacy  of  tke 
driving  cycley  cat  be  considered  a a  mapping  tke  traaaitioa  to  tkie  property’s 
domaia.  Uaiag  tke  above  mapping,  a  model  of  a  ajratem  caa  refect  either 
coaaiateacy  or  iaroaeieteary. 

e  A  eyatem  ia  coaetdered  consist**!  IFF  there  exiata  a  poeithre- integer  map¬ 
piag  to  eack  traaaitioa,  rack  that  at  every  place  p,,  tke  earn  of  the  integer* 
oa  Ip{fi)  eqaala  the  earn  of  tke  iategen  oa  0,(pt). 

e  A  eyatem  ia  coaaidared  inconsistent  if  it  either  prodacee  aa  iafiaiu  number 
of  token*,  or  coaaumaa  tke  token*  and  atop*. 

Ia  practice,  tke  integer  awigameat  to  eack  traaaitioB  give*  a  poeaible  relative 
firin§-fr*i%tncj  to  tke  traaaitioa.  Coaaiateacy  caa  be  detected  by  aolving  the 
local- balance  equation*  described  above,  and  finding  a  eolation  with  no  con¬ 
tradiction*.  Aa  caa  be  seen  in  the  model’a  description,  th*  firing-frequency  of 
each  transition  is  rooted  ia  th*  driving  cycle.  An  emphasis  should  also  be  put 
oa  the  difference  between  this  approach  and  the  classical  Petri  net  approach. 
The  transitions  here  fire  immediately  after  being  enabled,  while  the  firing  in  the 
daeekal  approach  ia  non-deterministic .  Therefore,  hare  the  firing-frequency  of 
each  transition  caa  either  be  computed  definitely  (all  decisions  in  the  path  are 
predetermined),  or  bound*  can  be  aet  (ia  cnee  there  sxista  a  data  dependent 
decision  in  the  path). 

Proving  Safeneea  in  Presence  of  Time 

The  construction  methodology  given  above  guarantees  the  reachability  of  the 
placet  ia  the  network.  Yet,  if  thia  network  ia  interpreted  ia  the  classical  Petri 
aet  orientation,  the  master  timing  mechanism  of  the  model  -  the  driving  cycle 
-  doss  not  preserve  safeness  property,  by  allowing  "exponential  explosion*  of 
the  tokens  population  in  the  network.  Therefore,  in  [10]  the  property  "safe  in 
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tbs  pwwci  at  tiaM*  is  istrodsod,  aad  tbs  timing  restrictions  for  this  property 
in  derived,  to  bold  far  socb  of  lbs  m*  tosOnds  introduced  ibow.  A  brisf 
summary  of  tbs  restrictions  is  pm  below. 

flefanese  far  «fanpb  plocoo.  A  'simple  place*  is  a  pUcs  pi  with  |/r(pi)|  *  1 
sad  \Op(fi)\  >  1,  socb  tbit  sack  Inasilioo  t*  ia  its  ostpst  set  satisfies 
|A(*a)|  m  1.  Ia  [10j  it  is  proved  that  socb  a  simple  place  is  proved  to  be 
sals  ia  prsssaci  at  time  ia  tbs  worst  csss  IFF 

Ti  £  I\/F, 

where:  Ti  is  tbs  exscutioa-time  of  this  place,  7\  is  tbs  cycW-tims  of  tbs 
driving  cycle,  aad  F,  is  tbs  MRFF  at  tbs  iapoWtraaaitioa  to  this  place. 

Saflmaas  far  final  piacaa  tat  parallel  path.  Tbs  final  places  pfi  (»  -  l..n), 
of  a  syaebroaised  parallel  coastroct  with  a  parallel  paths,  are  each  foend 
safe  ia  prsssacs  of  time  ia  tbs  worst  case,  IFF  far  each  of  tbsm 

Vy  €  l..n  :  Pj  -  Pi  <  ( Ti/F/i )  —  T/i 

wbsre:  Pj  is  tbs  total  path  time  (execution  +  waiting)  of  path  V ,  F/i  is 
tbs  MRFF  a t  tbs  iapat  traasitios  to  p/i,  aad  T/i  is  tbs  execution  time 
at  p/i  itself. 

Safansaa  far  entry  piacaa  of  independent  cyelee.  Cyds-tims  (  T0  )  is  tbs 
tune  imterral  from  bring  of  ti  to  "token  ready*  ia  p/.  Tbs  exacutioa  time 
of  tbe  entry  placs  is  denoted  ss  T„  sad  tbs  MRFF  at  tbs  iapat  transition 
to  entry  placs  is  denoted  as  F«.  Ia  (10)  it  is  proved  that  aa  entry  placs  to 
aa  independent  cycle  construct  is  safe  ia  prsssacs  of  time  IFF 


T,  <  Ti/F,  aad  Tc  <  Tt/F.. 


An  outcome  of  this  result  is  that  if  p,  ia  safe  ia  prsssacs  of  time,  then 
waiting  time  for  all  tokens  arriving  to  this  placs  is  serw. 

Safeness  far  placer  in  a  shared- resource.  A  shared  cycle  time  Tck,  for  a 
cycle  containing  tuisa  shared  resource  construct,  is  the  time  that  elapses 
from  firing  of  Uk  until  the  token  arrives  at  p/.  It  is  proved  (in  [10|)  that 
given  that  all  the  entry  places  receive  from  identical  MRFF s,  and  the 
MTIAT  of  the  entry  places  is  their  execution  time  divided  by  the  MRFF, 
then  each  entry  place  p,,  (to  a  shared  resource  construct)  is  safe  in  the 
presence  of  time  IFF 

fa 

T.y  +  53  Tck  <  Taj  +  Ti/F.. 

hml 

For  all  the  above  constructs’  types  the  regularity  of  the  net  timing  is  pre¬ 
served. 


I 
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CooUkaa  aad  Roaeopoaloe  mail  tka  method  they  nn«K  ia  [10].  The  w**k- 
mm  potato  they  tad  ia  U«r  approach  an 

•  The  neaito  an  vary  aaoaitiv*  to  ckaagee  ia  prnraai  or  path  axecatioa  tima. 

a  Aa  alteration  coaatract  ia  aaadad. 

a  Tka  raatrktioa  oa  a  akarad  raaoarca  (limited  only  to  tka  caaa  of  idoatical 
Criaf  rataa)  ia  too  strong. 

Tka  advaatagaa  tkay  tad  ia  it  an: 

a  Tka  ability  to  formally  aad  explicitly  txpreaa  tka  timiag  conatraiata. 
a  Tka  aatomat ability  of  tka  matkod. 

a  Tka  ability  to  verify  timiag  pro  pert  iae  ia  tka  daaiga  pkaaa. 

Two  otker  daficianciaa  akoald  be  coaaidand.  Firat,  tka  abeance  of  perfor- 
maace  aaalyaia  took,  doaa  aot  allow  tka  examiaatioa  of  timiag  problem*  ratkar 
tkaa  aafaaaaa  (a.g.  bottU-nack).  Second,  tka  natrictioaa  impoeed  in  tka  con- 
etractioa  of  tka  aat,  narrow*  significantly  tka  caaae  tkat  can  be  treated. 


Chapter  3 


Development  in  A  Real 
Time  Environment 


3.1  General 

When  the  design  pkw  is  complete,  aad  a  periled  solution  for  a  gives  problem 

Sow  software  engisswiag  rmarck  triad  to  evalaate  the  approach  adopted  ia 
projects  smog  nrioes  criteria,  as  the  chaages  histslled  ia  a  program  dariag  its 
Ms  cycle  [•],  hat  oaly  few  works  tried  to  evaluate  the  approach  bom  the  tiauag 
point  of  view.  As  emphasised  before,  real  time  software  perfonaaace  depeads 
highly  oa  the  implementation,  aad  therefore  the  deftaitioa  of  the  environment 
is  of  cracial  importaace.  The  development  environment  iadades  the  proces¬ 
sor  ssed,  the  operatiag  system,  the  laagaage  aad  its  compiler  aad  roa  time 
libraries,  the  artwork  stractmre  ia  which  a  distributed  compatatioa  takes  place, 
aad  special  aids  ased  dariag  the  implemeatatioa  phase.  Soma  attempts  have 
bees  made  to  allow  proper  ideatifleatioa  of  this  eariroameat  (e.g.  [20]),  aad 
experieace  eras  samm vised  iato  reconuneadations  (e.g.  (lj),  bet  probably  the 
most  importaat  areata  ia  real  time  software  implemeatatioa  ia  the  last  decade 
are: 


e  The  etaadardiaatioa  of  the  Ada  programming  laagaage  by  the  U.S.  De¬ 
partment  of  Defease. 

e  The  adoption  of  MASCOT  by  the  U.K.  Ministry  of  Defense. 

This  chapter  tries  to  highlight  some  important  aspects  concerning  real  time 
software  implementation;  Starting  with  the  influence  of  the  design  approach 
adopted,  reviewing  an  aatomated  tool  which  translates  a  model  to  a  program, 
emphasising  the  importance  of  the  programming  discipline,  and  concluding  with 
two  importaat  aspects  concerning  programming  with  Ada. 
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3.2  Approaches 

Specifying  *  eyfm  ia  a  conventional  approach  treats  tk«  system  aa  a  “black 
bos* ,  dmcribmg  who*  bat  mot  kcw.  Ia  othar  words,  wk«a  w«  start  the  realisa¬ 
tion  phsss  (adopting  ths  conventional  approach)  the  sxtsnal  bsharior  is  wsll 
dsiasd,  while  ths  iatsraal  structure  is  aot.  Top  down  disciplias  is  maiataiasd 
throughout  ths  whols  darslopmsat  phass,  which  msaas  that  implemsatation 
couutraiata,  ahhoagh  kaoara  from  ths  vary  bsgianiag,  are  iatsatioaally  ignored. 
Sosas  trials  have  bssa  mads  ia  iaformatioa  processing  projscts  (as  ths  Jackson 
deveiopmuut  approach)  to  find  bsttsr  eolations.  Ths  PA  IS  Ley  project  anas  a  new 
approach  ia  real  time  system  development,  ia  which  these  ideas  are  organised 
into  a  strategy  called  operational  approach  [35].  Ths  main  idea  ia  that  external 
behavior  and  internal  structure  may  interleave.  Yet,  operational  approach  sepa- 
rates  the  problem- oriented  structure  of  the  operational  specifications  from  pure 
implement  a  tie  a  considerations.  The  operational  specifications  themselves  are 
written  ia  aa  operational  specification  language,  which  is  executable  and  pre¬ 
vents  ambigaitim  Transformational  implementation  would  therefore  guarantee 
correctness  of  the  prod  need  code.  Although  this  approach  seems  to  lead  to  a 
very  easy  implementation  phase,  the  problems  of  stringent  timing  constraints 
do  not  dieeppter  -  they  can  be  found  in  the  generation  of  the  transformational 
implementation. 


3.3  From  a  Model  to  a  Program 

In  chapter  2  of  this  paper,  the  Petri  net  models  were  introduced.  For  systems 
which  contain  concurrent  processing  considerations  and  dynamic  sequential  de¬ 
pendencies,  this  modeling  technique  seems  exceptionally  suited.  Nelson  et  al  [28] 
introduce  a  method  of  translating  a  Petri  net  model  into  a  procedural  language 
program,  and  this  method  is  reviewed  in  this  section. 

3.3.1  Annotated  Petri  Nets 

The  commonly  need  Petri  nets  are  extended  by  means  of  annotations  and  initial 
considerations  that  provide  processing  content  and  external  dependencies  to  the 
firing  of  the  net. 

1.  Actions  that  do  not  relate  to  the  net  itself  (e.g.  applying  a  function  to  a 
specific  data  structure,  firing  another  net,  calling  a  procedure)  are  assigned 
to  transitions  with  a  corresponding  annotation. 

2.  Boolean  expressions  that  express  external  dependencies  are  assigned  through 
an  appropriate  annotation  to  output  ares  of  a  transition. 

3.  An  integer  selector  may  be  assigned  to  a  transition.  When  this  transition 
fins,  at  most  one  of  its  output  places  will  be  marked. 
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4.  Two  ipteial  typo  of  transitions  an  tlkmd  to  have  only  in  pat  or  output 
arcs:  the  initial  sad  the  terminal  transitions. 

3.3.2  The  Method  of  Translation 

Sack  nods  in  tka  astwork  (either  a  transition  or  a  pines)  is  ralatad  to  a  specific 
template  of  statsmsats.  Tka  template  coatant  depends  oa  tka  noda’s  type,  its 
fan-out,  and  tka  annotation  assign  ad  to  it.  combining  tkasa  tamplatas  rasults 
ia  a  program  ia  a  procadnral  laagaaga  callad  XL/1,  aad  tkis  program  is  then 
(via  aa  antomatad  procsss)  translatad  to  PL/I  or  PL/S. 

3.3.3  Multiprocessor  Environment 

Pstri  ast  theory  doaa  not  fores  a  fireable  transition  to  firs,  bat  if  a  transition  fine 
tka  firing  ia  complata  aad  conan  maa  aaro  time.  Implementing  a  transition  firing 
witk  n  program  imposes  n  non-isstsstanaons  firing.  Wkaa  tka  environment  is  of 
a  mnltiproraaaor  ayatam,  a  matmal  aaclaaioa  device  mast  protect  tka  firing,  since 
non  tkaa  one  procaaaor  may  be  foensed  mi  particular  input  places  at  a  specific 
time.  Therefore,  tka  autkors  provide  a  aamapkora-lilca  lockup  mackanitm,  and 
an  stomac  operation  which  adjusts  (increment  or  decrement)  tka  number  of 
tokens  ia  places.  All  the  placss  that  an  associated  witk  a  specific  lock  are 
assigned  (according  to  given  rules)  to  a  lock-sat,  which  governs  their  access  to 
tka  lock. 

3.3.4  Conclusion 

Although  tka  mechanism  propoeed  ia  [28]  is  not  optimised,  especially  for  hard 
real  time  applications,  it  provides  a  very  good  tool  for  tka  design  verification.  If 
further  work  will  be  done,  architectural  optimisation  may  be  performed  by  the 
XL/1  automaton,  imposing  the  constraints  aad  the  implementation  dependent 
properties  of  the  system. 

3.4  Implementation  Discipline 

The  complexity  of  programming  increases  when  we  step  from  sequential  to  mul¬ 
tiprogramming,  aad  it  increases  further  when  we  apply  real  time  programming. 
A  set  of  concepts  (for  reasoning)  and  a  set  of  /eeditie*  (for  description)  is  added 
in  each  step.  Adding  synchronisation  sign  ala  and  mutual  axclusion  devices  to 
sequential  programming  allows  us  to  uss  multiprogramming,  and  adding  to  it 
execution  speed  allows  dealing  witk  real  time  programming.  Bat  the  complexity 
of  reasoning  iacreaaee  by  a  new  dimension.  In  [S4[  a  summary  of  all  the  needs 
for  real  time  programming  discipline  is  given  and  analysed. 


3.4.1  Making  a  Real  Time  Program  Manageable 

la  ord«r  to  auki  a  real  tim«  program  manageable,  Wirth  suggest*  the  following 
recipe: 

1.  Pint  formulate  the  entire  program  without  reliance  on  execution  times. 
All  necessary  synchronisation  signals  should  be  provided  explicitly. 

2.  If  the  machinery  to  be  used  does  not  provide  some  of  the  necessary  syn¬ 
chronisation  signals,  derive  analytically  the  timing  constraints  for  each, 
sad  allow  its  absence. 

3.  Check  whether  the  constraints  are  satisfied  by  the  computer  system. 

3.4.2  Synchronisation  Discipline 

In  a  distributed  environment,  processes  commonly  synchronise  using  signals 
and  semaphores.  A  semaphore  is  equivalent  to  a  signal  with  associated  mem¬ 
ory.  Sending  an  unconditional  signal,  when  no  process  is  waiting,  may  lead 
to  aa  un traceable  system  crash.  This  mistake  is  commonly  made  due  to  as¬ 
sumptions  taken  over  the  computation  speed  of  the  different  processes.  Hence, 
declaring  await(s)  as  a  necessary  precondition  of  send(s)  is  recommended,  when 
occurences  as  below  might  exist: 

Pi:  ...SI;  send(s);  ... 

P2:  ...S2;  await (s);  ... 


3.4.3  Language  and  System  Requirements 

The  form  and  structure  of  a  real  time  programming  language  are  as  important 
as  in  regular  distributed  programming.  No  additional  structural  concepts  are 
needed  for  a  real  time  programming  language: 

1.  A  notational  unit  for  describing  processes  (themselves  sequentially  exe¬ 
cuted)  that  can  be  executed  concurrently,  and  noninterruptably. 

2.  A  collection  of  shared  variables  and  their  operators. 

3.  An  object  to  trigger  communication  after  waiting  (signals). 

Yet,  an  additional  feature  is  needed: 

•  A  facility  which  provides  accurate  execution  time  bounds,  as  an  additional 
part  of  an  existing  compiler.  If  the  compilation  is  straightforward  (i.e.  no 
optimisation  is  performed),  the  use  of  a  simple  execution  time-table  of  the 
statements  is  poesible. 
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An  important  recommended  concept  is  the  coherency  of  logical  processes 
(each  one  is  implemented  as  if  it  owns  a  private  processor).  Two  feat  ores  that  are 
achieved  applying  this  concept  are  the  simple  logic  foundation  of  the  program, 
and  the  maximal  degree  of  freedom  left  for  choosing  processor  sharing  strategy. 

When  applying  processor  sharing  policy,  the  static  time  bounds  (prepared 
in  a  straightforward  time-table)  do  not  hold;  the  processor  may  be  attached  to 
another  process  for  an  unknown  ‘time  slice*. 

3.4.4  High  Level  Language  and  Processor  Sharing 

Most  of  the  uncertainties  in  execution  time  are  due  to  tasks  performed  by  an¬ 
other  process.  The  author  uses  the  notation  ‘doio*  (as  in  DO  I/O)  for  the 
following  sequence: 

...send(initiation);wait(completion)... 

and  applies  a  ‘hidden*  delay  statement  behind  each  ‘doio*  statement.  The 
delay  is  derived  from  the  execution  performances  and  the  strategy  chosen  for 
the  processor  sharing  (priority  plays  a  major  role  here). 

3.4.5  Recommended  Discipline  for  Real  Time  Program¬ 
ming 

1.  Time  dependent  program  parts  executed  externally  (by  a  device  process), 
should  be  restricted  to  nonin terruptable  execution  mode. 

2.  Execution  time  of  the  above  program  parts  is  determined  statically. 

3.  Each  ‘doio*  is  assumed  to  have  a  hidden  delay,  derived  as  stated  above. 

This  discipline  may  lead  to  high  time  consuming  delays,  and  the  proposed  so¬ 
lution  is  a  priority  interrupt  system,  which  requires  adherence  to  the  following 
constraints: 

1.  Every  device  process  Pi  is  cyclic,  consisting  of  a  statements  sequence  Si, 
and  the  ‘doio*  represents  the  waiting  for  device  completion. 

2.  U  =  T(Si)  +  T(doioi).  The  cycle  time  of  Pi,  at  any  priority  level,  is 
considerably  greater  than  that  of  all  other  processes  at  higher  priority. 

3.  The  ratio 

r  T(Sj) 

T(Si)  +  T(doioi) 

over  any  cycle  is  very  small  (  <  1). 

4.  Each  signal  emitted  by  a  device  must  be  awaited  by  single  (regular)  process 
only. 
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5.  A  device  proceee  most  never  ii*«//invalidate  the  condition  associated  with 
the  signal  it  emitted. 

3.5  The  Ada  Programming  Language 

The  Ada  programming  language  [2]  was  designed  as  a  common  language  for 
programming  large  scale  and  real  time  systems.  The  Ada  programming  language 
has  introduced  many  high  level  facilities,  but  in  this  review  only  one  innovation 
is  examined.  The  tasking  facilities  have  always  been  a  part  of  the  operating 
system,  rather  than  the  programming  language,  until  Ada  has  been  introduced. 
Furthermore,  synchronisation  of  these  facilities  has  used  primitives  provided  by 
the  operating  system,  invoked  usually  as  ‘system  calls”  from  a  very  low  level 
part  of  the  program.  The  Ada  programming  language  includes  both  the  tasking 
facilities,  and  the  synchronisation  tools  as  a  part  of  the  language.  This  feature 
allows  the  programmer  to  concentrate  on  parallel  system  design  and  to  ignore 
inter-task  synchronisation  and  communication  details. 

Parallel  processes  are  called  tasks  in  the  Ada  language.  Each  task  may 
have  some  entries,  which  are  called  from  other  tasks.  Two  tasks  interact  by 
first  synchronising,  then  exchanging  information  and  finally  continuing  their 
individual  activities.  This  synchronised  meeting  to  exchange  information  is 
called  rendezvous.  This  concept  is  based  on  Hoare’s  CSP  proposal  [19]  for 
concurrent  programming,  and  Ada  is  the  first  language  that  has  adopted  it. 
Hence,  this  is  the  only  experience  in  using  this  concept,  and  recent  works  have 
shown  some  interesting  aspects  in  implementing  it. 

Two  important  issues  concerning  the  rendesvous  are  reviewed  in  this  section: 
the  implementation  of  the  concept  in  the  compiler  level,  and  the  implementa¬ 
tion  of  the  concept  in  the  program  level.  As  stated  below,  both  may  lead  to 
inefficiencies  and  undesirable  effects. 

3.5.1  Implementing  Tasking  Facilities 

Three  ways  of  implementing  the  rendesvous  concept  in  the  compiler  level  are 
examined  in  [14].  The  paper  also  examines  results  of  the  three  implementations 
in  PASCAL  to  validate  the  analysis.  The  mechanism  and  the  implementations 
are  described  below. 

Assumptions  and  Description  of  the  Mechanism 
The  assumptions  taken  in  [14]  are: 

1.  The  Ada  kernel  is  implemented  as  a  set  of  primitives.  An  exact  copy  of 
this  set  resides  on  the  private  memory  of  each  processor  which  participates 
in  executing  the  concurrent  program.  The  interaction  between  tasks  that 


these  primitives  allow,  is  independent  of  the  physical  allocation  of  the 
tasks. 

2.  The  executable  code  for  each  processor  resides  on  its  private  memory. 

3.  Some  data  constructs  are  located  in  the  system  shared  memory. 

4.  Each  task  descriptor  consists  of  two  parts:  global  and  local  task  descrip¬ 
tors.  The  local  task  descriptor  resides  on  the  private  memory  of  the  pro¬ 
cessor  which  runs  this  task.  It  contains  all  the  information  required  to 
run  this  task  concurrently  with  other  tasks  resident  on  the  same  processor 
(i.e  state-word,  status  field,  task  priority,  scheduling  time,  links  to  other 
local  task  descriptors,  a  link  to  its  own  global  task  descriptor).  The  global 
task  descriptor  resides  on  the  system  shared  memory.  It  contains  all  the 
information  required  to  allow  interaction  between  tasks  that  are  allocated 
in  different  processors  (i.e.  processor  Id,  a  lock  variable  for  mutual  exclu¬ 
sion,  status  field,  pointer  to  actual  parameters  list,  a  set  of  addresses  of 
entries,  a  set  of  queues  -  one  for  each  entry,  a  stack  of  invoking  tasks  Id’s, 
a  link  to  its  own  local  task  descriptor). 

5.  Each  processor  can  send  interrupt  signals  to  any  other  processor. 

The  task  management  mechanism  suggested  in  [14]  is: 

1.  When  a  task  invokes  the  kernel  to  interact  with  another  task,  the  invoked 
primitive  (executed  by  the  processor  on  which  the  calling  task  resides) 
checks  the  global  descriptor  of  the  called  task. 

2.  IF  the  called  task  resides  on  the  same  processor  as  the  calling  one,  THEN 
all  the  required  information  concerning  its  status  is  available  in  the  local 
descriptor. 

3.  IF  the  called  task  resides  on  a  different  processor,  THEN  the  primitive 
which  has  been  invoked  sends  an  interrupt  request  to  that  processor,  spec¬ 
ifying  the  calling  processor,  the  called  task,  and  the  requested  operation. 
The  interrupt  service  procedure  will  then  invoke  the  kernel  primitive  which 
correspond  to  the  requested  operation,  to  complete  the  interaction. 

Implementation  of  the  Mechanism 

Three  possible  implementations  for  the  above  mechanism  are  described  below. 
The  comparison  criteria  are  minimising  system  overhead,  and  the  task  blocking 
time. 

“Server”  Rendezvous  is  the  first  possibility  to  implement  the  mechanism. 
In  this  implementation  the  calling  task  remains  suspended  until  the  called  task 
executes  the  accept  body  (see  [2]  for  description  of  the  accept  statement).  This 
implementation  has  advantages  and  deficiencies  which  are  listed  below. 


1.  A  tingle  copy  of  the  accept  body  is  sufficient,  and  it  should  be  stored  in 
the  private  memory  of  the  accepting  processor. 

2.  In  order  to  complete  the  rendesvous,  the  scheduler  is  invoked  (possibly  a 
context  switch  occurs)  twice  in  the  case  that  the  entry  calling  execution 
precedes  the  accept  execution,  and  three  times  otherwise.  One  or  two 
inter-processor  interrupt  signals  are  required,  and  two  or  four  scheduling 
operations  (respectively)  are  necessary,  if  the  interacting  tasks  are  running 
on  different  processors. 

3.  Parameter  passing  may  be  carried  out  through  the  shared  memory. 

"Procedural  Call”  rendesvous  is  another  possible  implementation.  Here 
the  accept  body  is  always  executed  by  the  calling  task.  This  approach  has  the 
following  properties: 

1.  Accessibility  of  the  accept  body  can  be  obtained  either  by  keeping  an  ex¬ 
act  copy  of  the  accept  body  on  each  private  memory  of  a  processor  that 
runs  the  calling  task,  or  by  storing  the  accept  body  in  the  shared  memory. 
The  shared  memory  solution  is  exactly  the  same  as  the  “server”  solution 
(communication-wise).  The  replication  solution  may  be  ineffective  or  im¬ 
possible  if  a  resource  needed  for  the  accept  body  is  only  available  to  a 
particular  processor. 

2.  No  special  mechanism  of  parameter  passing  is  needed,  since  the  caller 
executes  the  accept  body  in  its  thread  of  control. 

“Order  of  Arrival”  rendevous  is  a  solution  provided  by  the  authors  of 
this  paper  ([14]),  and  it  reduces  the  scheduling  points  required.  Here,  the  accept 
body  is  executed  as  a  part  of  the  thread  of  control  of  the  last  task  which  joins 
the  rendesvous.  The  properties  of  this  approach  are: 

1.  In  the  case  of  a  mono- processor  system  only  two  scheduling  points  are 
needed. 

2.  In  the  case  of  tightly  coupled  multi-processor  system,  one  inter-processor 
interrupt  signal  and  two  scheduling  operations  are  needed  to  complete  a 
rendesvous. 

3.  The  same  resource  allocation  difficulties  that  were  introduced  in  the  "pro¬ 
cedural  call*  approach  exist  here. 

The  differences  between  the  three  approaches  emphasise  the  significance  of  the 
compiler-level  implementation,  for  the  timing  performances  as  well  as  for  the 
communication  economy  of  a  system. 


3.5.2  The  Tendency  to  Poll 

Experience  in  using  the  rendezvous  concept  when  programming  in  Ads,  is  sum¬ 
marised  in  [15],  pointing  out  a  tendency  to  apply  polling  policy,  which  is  usually 
(but  not  always)  undesirable  because  it  is  wasteful  of  system  resources.  A  re¬ 
view  of  this  findings  and  the  suggestions  provided  in  the  above  paper  are  given 
below.  But  first,  four  assumptions  concerning  the  rendezvous  mechanism  must 
be  taken  into  account: 

1.  Two  tasks,  A  and  B,  rendezvous  at  entry  E  of  B,  when  A  calls  entry  E, 
and  the  entry  call  is  accepted  by  B. 

2.  IF  A  calls  the  entry  call  before  B  is  ready  to  accept  the  entry  call,  THEN 
A  waits  until  B  is  ready. 

3.  IF  B  is  ready  to  accept,  THEN  it  must  wait  until  some  task  issues  that 
entry  call. 

4.  Calls  to  a  specific  entry  are  executed  in  FIFO  order. 

The  Rendevous  Statements 

Two  types  of  rendezvous  statements  are  permitted  by  MIL-STD-1815A  [2],  the 
selective  wait  statement  and  the  conditional  entry  call. 

1.  The  Selective  Wait  Statement l. 


select 

[when  cond  =>]  selective. wait  .alternative 
{or 

[when  cond  =*•]  selective  .wait  .alternative} 

[else 

aequence.of .statements  ] 
end  select; 


The  selective  wait  statement  is  used  for  waiting  and  selection  from  one  or 
more  alternatives.  A  selective.wait.alternative  is  restricted  to  the  follow¬ 
ing: 

e  A  delay  or  an  accept  statement,  followed  by  a  sequence  of  statements, 
e  The  terminate  alternative. 

1[..]  -  stands  tor  optional  statement.  {..}  -  stands  for  sero  or  more  times. 
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The  selective,  wait  .alternative  is  non-determ  inistically  selected  from  the 
set  of  ‘open”  accept. alternatives  for  which  a  rendevons  is  immediately 
possible  (if  the  set  is  nonempty).  The  approach  is  adopted  from  [19].  A 
delay  .alternative  is  selected  if  no  accept.alternative  can  be  selected  before 
the  specified  delay  has  elapsed.  If  no  selective. wait  .alternative  can  be 
selected,  the  else-part  (if  nonempty)  is  executed.  If  no  accept.alternative 
is  immediately  possible,  and  there  is  no  else-part,  then  the  task  watts  until 
such  an  alternative  will  become  open. 

2.  The  Conditional  Entry  Call. 


select 

entry  .call  .statement  [  sequence,  of  .statements  ] 

else 

sequence. of  .statements 
end  select; 


Although  the  syntax  is  quite  similar  to  that  of  the  selective  wait  statement, 
they  are  semantically  opposite:  the  selective  wait  is  used  in  accepting 
entry  .calls,  while  the  conditional  entry  call  is  used  for  making  entry  .calls. 
IF  the  rendesvous  is  not  immediately  possible,  THEN  the  entry  .call  is 
canceled,  and  the  else-part  is  executed. 

Polling 

Polling  is  characterised  by  a  task  actively  and  repeatedly  checking  for  an  oc- 
curance  of  an  event  that  originates  externally  to  the  task.  The  paper  ([15]) 
distinguishes  two  types  of  polling: 

1.  Task  A  rendevons  polls  with  task  B  (with  respect  to  entry  E)  IF  the 
rendesvous  can  be  preceded  by  an  unbounded  number  of  attempts  by  A. 
(Attempt  is  defined  as  an  unsuccessful  entry  call  OR  a  failure  to  select  an 
accept.alternative  in  a  select  statement.) 

2.  Task  A  information  polls  with  task  B  (with  respect  to  entry  E)  IF  A  and 
B  can  rendesvous  an  unbounded  number  of  times  before  information  is 
exchanged. 

A  bnsy  waiting  situation  is  identified  if  between  rendesvous  attempts  no 
computational  progress  is  achieved.  The  polling  is  usually  wasteful  of  resources 
-  it  simply  burns  up  CPU  cycles.  Furthermore,  it  may  unnecessarily  load 
the  communication  network  very  heavily.  Another  dangerous  situation  hap¬ 
pens  when  the  calling  and  the  called  tasks  both  symmetrically  loop  over  a 


sslective.wait  .statement  mad  a  conditional  jen  try  .call  with  an  elae-part:  the  ren- 
desvous  may  never  occur!  Yet,  sometimes  polling  is  desirable:  when  non-polling 
may  result  in  snch  an  additional  overhead  that  might  violate  real  time  con¬ 
straints.  Bat  these  cases  are  very  rare,  and  should  be  definitely  identified  and 
justified. 

Bins  Towards  Rendevoua  Polling 

The  tendency  to  poll  when  implementing  the  Ada  rendetvous  is  encouraged  by 
the  following: 

•  Lack  of  some  facilities. 

•  Restrictions  imposed  by  Ada. 
e  Presence  of  some  facilities. 

Four  encouragements  for  polling  are  given  below. 

Conditional  Entry  Call  should  be  used  with  care,  since  it  may  lead  to  unnec¬ 
essary  polling.  Consider  the  poor  example  given  in  [2]  paragraph  9.7.2.7: 


procedure  SPIN[R  :  RESOURCE)  le 
begin 

loop 

select 

J2.SEIZE ; 
return  ; 

else 


end  ; 


null  ;  -  busy  waiting 
end  select  ; 
end  loop  ; 


The  ‘busy  waiting*  is  really  unnecessary. 

Handling  an  Entry  -  Family  is  generally  expressed  as  a  polling  loop.  For 
example,  let  X  be  an  entry-family  that  have  N  members,  declared  as  entry 
X(Y),  while  Y  is  of  subtype  integer  that  ranges  from  1  to  N.  The  skeleton 
of  the  program  that  accepts  call  for  the  entry-family  usually  looks  like: 


loop 


for  /  €  Y:  loop 
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■elect 


eccept  X(I)  do  ...  end  ; 

else 

null ; 
end  select  ; 

end  loop  ; 
end  loop  ; 


This  select  statement  polls  unnecessarily,  and  eolation  may  be  given  either 
by  replacing  the  “for*  statement  by  an  N  specific  ORed  accept. statements 
with  no  eise-part  (only  for  a  small  known  N  !),  or  by  a  different  design 
which  makes  a  use  of  the  entry  family  indices. 

Restrictions  on  Selective- Wait-Statement  of  two  types  are  imposed. 

1.  Not  allowing  a  wksn  condition  followed  by  a  sequence  of  non-tasking 
statements  as  a  select  alternative ,  which  is  needed  as  follows: 


loop-  illegal  example 
■elect 


or 

when  cond  A  :*  B  ;  -  illegal  I! 

end  select  ; 
end  loop  ; 

The  above  implementation  is  illegal  since  only  accept/  delay/  termi¬ 
nate  are  allowed  as  alternatives.  The  use  of  an  else  -  if  statement  to 
replace  the  illegal  statement  is  wrong,  since  it  would  be  executed  to 
no  effect  (again  and  again)  when  any  feasible  alternative  is  absent. 
Hence, 


loop-  better  solution 

■sleet 


or 

delay  0.0  ;  -  sero  delay  is  legal 
A:-B; 
end  select  ; 
end  loop  ; 
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2.  The  leek  of  selective  .call  statement  end  not  allowing  eny  entry. call 
ea  e  select  alternative,  which  ere  needed  as: 

loop-  illegal  form 
•elect 

call-entry  X.E  ; 
or 

call-entry  Y.F  ;  -  illegal !! 
end  select  ; 
end  loop  ; 

Replacing  the  illegal  “or"  pert  by: 

else 

■elect 

calLentry  Y.F  ; 

else 

null  ; 
end  select  ; 

is  wrong  for  two  reasons:  it  gives  preference  to  X.E  and  the  inner 
select  polls  again.  Another  problem  arises  when  we  need  an  entry 
call  as  a  select  alternative: 

loop-  illegal  form 
■elect 

when  B  w  accept ... 
or 


or 

when  C  w  calLentry  Y.F  ;  -  illegal !! 
end  select  ; 
end  loop  ; 


Since  the  above  program  is  illegal,  one  is  tempted  to  replace  the  "or 
when  C  ..."  with: 

else 

if  C  then 

■elect 
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calLentry  Y.F  ; 

ela« 
null ; 

end  select  ; 
end  if ; 

This  replacement  may  lead  to  a  dangerous  situation,  especially  when 
X  and  Y  are  symmetrical,  since  a  simultaneous  polling  becomes  pos¬ 
sible,  and  the  rendesvous  may  never  occur. 

The  "else”  clause  in  a  selective-wait-statement  is  the  highest  temptation 
to  poll.  Therefore  a  careful  examination  should  be  taken:  IF  the  alterna¬ 
tive  action  is  not  really  a  part  of  the  task,  THEN  it  should  be  encapsulated 
in  another  task,  which  could  result  in  the  elimination  of  the  polling.  A 
good  design  approach  separates  the  tasks  functionally  -  one  task  for  each 
function. 

Suggestions 

The  authors  provide  some  suggestions  to  changes  in  the  Ada  programming  lan¬ 
guage,  but  they  agree  that  “it  is  likely  that  the  Ada  programming  language  will 
not  be  modified,  at  least  not  in  the  near  future*.  Three  major  principles  pointed 
out  by  this  paper  should  be  adopted: 

1.  Use  a  delay  alternative  with  a  sero  delay,  to  allow  a  when  condition  fol¬ 
lowed  by  non-tasking  statements  as  a  select  alternative. 

2.  Separate  the  tasks  functionally  -  dedicate  one  task  Jot  each  function. 

3.  Take  a  lot  of  care  in  the  program  construction  to  avoid  unnecessary  polling. 
For  the  cases  in  which  polling  is  a  better  solution  than  others,  justify  it 
carefully. 


Chapter  4 


Verification  and  Validation 
of  Real  Time  Software 

4.1  General 

Vilification  of  programs  (i.e.  proving  that  a  program  moats  its  specification), 
may  bo  done  in  throe  major  methods: 

•  Using  an  assomatic  approach  to  infer  mathematical  and  logical  assertions 
which  describe  the  control  and  data  states. 

e  Using  Bot-Litu  or  Or sph  properties  to  obtain  the  required  proof. 

e  Ttttinf  the  program  for  the  relevant  inputs  it  may  meet  when  executed 
in  its  target  plant. 

The  axiomatic  approach  is  commonly  preferable,  because  assertions  can  be  com¬ 
municated  to  computers  via  compilers,  and  then  manipulated  by  simplification 
procedures.  Due  to  this,  proof  systems  for  many  design  and  development  ap¬ 
proaches  have  been  introduced.  Axiomatic  proof  systems  have  been  introduced 
for  distributed  systems  [29],  and  for  CSP  programs  [0).  Yet,  these  proof  sys¬ 
tem#  do  not  deal  with  timing  properties,  and  provide  no  means  for  real-time 
verification.  The  complexity  of  verification  grows  significantly  when  the  imple¬ 
mentation  ia  required  to  be  distributed. 

Moet  of  pest  works  based  their  proofs  (concerning  time  properties)  on  queue¬ 
ing  theory  [23],  proving  average  performence  criteria,  since  the  timing  charac¬ 
teristics  of  inputs  to  a  real  time  program  are  stochastic  by  nature,  la  addition, 
theee  works  supported  the  conclusions  by  tests  which  cover  the  inputs’  range. 

An  example  of  this  approach  is  described  by  G.  Anderson  [5],  combining  five 
methodologies  for  evaluating  performance  properties: 
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1.  Characterisation  of  work  load  to  the  propoaad  system. 

2.  Croat  ion  of  aa  approximate  queueing  model  for  the  ayetem,  and  evaluating 
average  performance  properties. 

3.  Identification  and  preparation  of  hardware  tools,  to  allow  measurements 
in  the  real  system. 

4.  Development  of  a  load-simulator,  to  allow  testing  under  a  controlled  load. 

5.  Modeling  the  system  with  a  detailed  simulator,  which  allows  bottle-necks 
identification  and  answers  to  'what  if*  questions. 

Anderson's  results  have  shown  good  match  between  expected  and  achieved  val¬ 
ues  (11%  in  response  time,  2%  in  CPU  utilisation),  yet  most  of  his  assumptions 
were  based  on  previous  experience,  which  is  always  needed  but  rarely  found. 

In  this  chapter,  various  methods  of  programs  validation  techniques  will  be 
reviewed,  starting  with  testing  real  time  performances,  followed  by  analysis 
and  proof  methods  for  real  time  properties,  and  finally  examining  the  use  of 
simulations  for  system  validation. 


4.2  Testing  Real  Time  Properties  of  Programs 

U.  Voges  and  J.  R.  Taylor  (30]  review  many  testing  approaches  and  procedures, 
all  sharing  the  same  goals:  proving  that  the  system  under  test  is  free  of  errors, 
and  obtaining  (when  it  is  possible)  some  figuroe  about  the  system’s  reliability. 

4.3.1  Systematic  Testing  Methods 

Tasting  Coverage 

Testing  a  system  thoroughly  means  testing  it  with  all  possible  combinations 
of  its  inputs.  In  exercising  input  sequences  of  a  distributed  system,  relative 
changes  within  aa  input  sequence  are  very  important  as  well  (e.g.  synchronisa¬ 
tion  problems),  a  property  which  may  lead  to  aa  enormous  sequence  of  inputs 
for  such  a  test.  An  early  approach,  suggested  a  design  criteria  of  asynchronous 
reproducibility  of  output  (for  a  set  of  inputs,  the  same  output  will  be  produced, 
regardless  of  speed  differences  or  time  intervals  at  which  the  inputs  are  deliv¬ 
ered).  Although  this  is  a  desired  goal,  sometimes  it  is  not  achieveable,  especially 
dealing  with  real  time  systems  in  which  a  deadline  criteria  should  be  met.  Yet, 
adopting  this  approach  in  the  design  even  partially,  reduces  significantly  the 
amount  of  required  input  sequences. 


CO 


"GUm-Bcoc”  Tasting  Method* 

Thk  method  k  applicable  especially  in  mod  ole- testing  level.  It  consists  of  an¬ 
alysing  the  module  reachable  paths,  comparing  the  calculated  path  predicates 
with  the  specification,  followed  by  symbolic  executions  of  the  tested  module. 
Its  major  disadvantages  are  the  ignoring  of  dependencies  between  modules,  the 
inability  to  deal  with  run  time  changee  of  control  logic,  and  the  inability  to 
pinpoint  a  missing  path. 

"Bluck-Booc”  Testing  Methods 

In  this  test  method  no  inside  look  k  concerned.  A  test  should  be  performed  both 
positively  -  a  functional  test  with  inputs  chosen  according  to  the  specification, 
and  negatively  -  reaction  to  abnormal  and  unspecified  events. 

Probe  Effects 

The  availability  of  "probing  points*  in  the  real  system  k  usually  limited.  In 
order  to  trace  control  flow  or  data  values,  additional  probing  statements  are  in¬ 
serted  to  the  program.  Therefore,  changee  regarding  the  environment  to  be  met 
in  the  real  operating  mode  are  introduced.  Hus  effect  k  of  extreme  importance 
when  dealing  with  a  hard  real  time  environment,  and  in  many  cases  disqualifies 
thk  testing  method. 

Example:  SADAT 

SADAT  [S3]  k  an  automated  test  tool,  which  supports  testing  of  a  single  FOR¬ 
TRAN  module.  SADAT  performs  the  following  test  procedures: 

e  Static  Analytic  -  Generates  the  program  control  graph,  in  which  sequen¬ 
tial  parts  are  represented  as  nodes  and  the  arcs  are  an  interpretation  of 
decision  to  decision  (d-d)  paths.  Thk  analysk  may  detect  unreachable 
statements  and  errors  in  control  Sow  that  the  compiler  failed  to  detect. 

e  Test  Cate  Generation  -  Produces  a  minimal  subeet  that  ensures  at  least 
one  execution  of  each  d-d  path. 

e  Path  Predicate  Calculation  -  Produces  the  path  predicate  for  every  path 
in  the  module,  and  runs  a  symbolic  execution. 

e  Dynamic  Analysis  -  A  control  statement  (in  the  form  of  a  subroutine 
call)  k  inserted  in  each  d-d  path,  allowing  accumulation  of  number  of 
executions  for  each  node.  Thk  output  can  be  used  to  track  a  dynamically 
"dead"  code,  optimisation  of  the  most  frequently  executed  parts,  and  for 
identification  of  additional  test  cases  that  are  required. 


SADAT  major  disadvantages  are  the  lack  of  distributed  and  real  time  properties 
testing.  Dealing  with  a  single  module  does  not  allow  any  concurrency  and  paral¬ 
lelism,  and  since  no  deadline  analysis  is  performed,  no  critical  timing  problems 
can  be  pin-pointed. 

Example:  TAS 

Ferranti  Computer  Systems  Ltd.  (UK)  developed  [13]  a  complete  environment 
they  use  for  software  development  and  validation  of  real  time  software,  using 
MASCOT  (Modular  Approach  to  Software  Construction,  Operation  and  Test¬ 
ing)  and  CORAL  (block  structured  language,  based  on  ALGOL60).  Their  test 
environment  consists  of  the  following  tools,  called  TAS  (Test  Aid  Suite): 

•  Unit  Driver  -  A  package  which  is  independent  of  the  software  under  test, 
that  provides  test  harness  and  allows  initialisation  of  set  up  values,  spec¬ 
ification  of  a  unit  (or  a  part  of  a  unit)  to  be  executed,  and  comparison  of 
results  obtained  to  those  expected. 

•  Path  analyzer-  Partitions  the  source  code  into  SubPath  Modules  (SPM’s). 
An  SPM  is  a  basic  block  containing  no  branch  points.  A  sequence  of  SPMs 
forms  a  subpath. 

•  Instrvmenter  -  Adds  to  the  source  code  necessary  “calls* ,  to  provide  “exe¬ 
cution  history”,  debug  facilities,  test  coverage  analysis,  and  static  analysis 
concerning  the  source  structure. 

Conceptually,  this  approach  is  very  similar  to  SADAT  (although  testing  a  struc¬ 
tured  language)  and  suffers  the  same  disadvantages. 

4.2.2  Statistical  Testing 

The  temptation  to  use  a  “sampled*  test  set,  originates  in  the  fact  that  the 
amount  of  different  inputs  required  to  test  a  program  systematically  may  become 
enormous  [30].  Yet,  the  smaller  the  sample  is  -  the  lower  the  reliability  is, 
therefore  a  decision  upon  the  sample  sise  must  be  calculated  carefully.  Typical 
results  of  statistical  testing  methods  are:  an  expected  value,  a  risk,  a  probability, 
confidence  limits  /  levels  of  significance,  variances.  In  real  time  software  testing 
a  particular  emphasis  is  put  on: 

•  Deadlock  occur ance. 

•  Correctness  of  a  sequence  of  outputs. 

•  Occur  ance  of  final/intermediate  results  in  the  right  time  interval. 


Risk  Calculation 

The  at  at  is  tic  el  testing  tries  to  save  test  runs,  and  thereby  to  reduce  cost,  but 
an  unfortunate  fact  of  decreasing  the  100%  proof  of  the  system  is  introduced. 
A  comparison  between  the  cost  reduction  and  the  risk  involved  is  therefore 
necessary.  One  way  of  defining  the  risk  cost  is  [30]: 

r=£ff(a)*(a) 

a 

,  where: 

e  X(a)  is  the  lost  caused  by  event  a. 

e  H(a)  is  the  frequency  of  “loss  causing  event*  a,  during  a  relevant  period 
of  time. 

•  H(a)=Ei^(t)P(o|t)P(a|a,-). 

e  H(i)  is  the  frequency  of  “initiating  event”  t  which  may  cause  a. 

•  P(«|»)  is  the  probability  that  the  system  under  test  will  fail  to  react  cor¬ 
rectly  on  i. 

•  P(a|o,)  is  the  probability  that  any  alternative  action  (installed  previously) 
fails  simultaneously. 

Simple  Cases 

An  analysis  of  the  probability  of  detecting  error-occurances  [30]  is  sketched 
below. 

First,  examining  the  probabilities  of  “hitting”  an  error. 

e  The  probability  of  hitting  one  error,  associated  with  time  interval  D,  in 
the  program  run  time  T,  with  no  condition  is:  P»,  =  D/T.  Hence,  for  N 
test  runs:  Pw„  =  1  -  (1  -  D/T)N. 

•  The  probability  of  hitting  one  error  in  one  test  run,  now  with  one  binary 
condition,  is:  P^i  =  1/2 D/T.  For  N  test  runs  and  k  binary  conditions: 
P*N  -  1  -  (1  -  (1/2)*  x  D/T)N. 

Now,  consider  the  case  of  sequence  of  tasks.  When  M  tasks  access  one  resource, 
there  are  M\  poceible  access  sequences.  If  we  assume  equal  probability  of  failure 
for  all  accesses,  then  the  probability  of  detecting  one  failing  access,  in  n  runs,  is 

P  *  1  -  (1  -  1/M!)" 
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.  If  the  M  taaka  access  N  resources,  the  number  of  possible  access  sequences 
becomes: 

N  U 

3=1 i=l 

•  rti  the  number  of  runs  of  task  t. 

•  rrii  j  the  number  of  accesses  to  resource  j  during  one  run  of  task  t. 

If  all  possible  accesses  are  to  be  considered,  then  the  number  of  sequences  be¬ 
comes  K\,  while  the  probability  of  hitting  error  is  known  from  above. 

The  presence  of  several  possible  priority  interrupts  in  a  time  interval  may 
trigger  several  task  sequences,  or  require  queue  rearrangements.  These  cases 
are  combinatorially  treated  the  same  as  the  access  problem  above,  keeping  in 
mind  that  deadlock  problem  may  occur  in  a  specific  sequencing. 

Testing  Large  Systems 

For  large  systems  a  slightly  different  approach  is  suggested  in  [30].  Defining  po 
to  be  the  probability  of  one  distinct  arbitrary  property,  we  would  like  to  obtain 
the  number  of  properties  (denoted  Nt)  we  have  to  test  for,  in  order  to  ensure 
Po  <  Po,  within  a  confidence  level  CL%.  Assuming  binomial  distribution  of 
properties’  error  detection  probability,  the  number  of  properties  we  have  to  test 
for.  . 

Nt  =  4.6/ Po  for  CL  -  99% 

Nt  =  3.0/ Po  for  CL  =  95% 

If  P0  is  between  10-7  to  10-4,  Nt  becomes  enormous.  Reducing  it  is  possible 
only  by  relating  to  previous  analysis,  performed  analytically  and  not  empirically. 
Obtaining  constraints  yields  simplification  of  the  testing  problem. 

Problems  With  Large  Tests 

The  large  number  of  runs  required  for  a  reasonable  confidence  level  sets  addi¬ 
tional  requirements  to  those  found  in  the  simple  cases: 

•  Testing  real  time  properties  is  implementation  (and  hardware)  dependent 
by  nature.  Hence,  the  system  should  b"  tested  as  a  whole,  while  the  tested 
computer  is  activated  by  a  computerised  test  equipment  (TE),  since  we 
require  a  large  number  of  runs. 

•  The  TE  provides  the  test  inputs,  controls  the  timing,  and  monitors  the 
outputs.  Hence  the  reliability  required  from  the  TE  is  very  high. 

e  If  a  random  number  generator  is  included  in  the  TE,  its  repetition  period 
should  be  sufficiently  long. 


•  The  statistical  analysis  shorn  clearly  that  in  cases  where  we  have  to  main¬ 
tain  reasonable  confidence  levels,  reduction  of  test  sequences  is  achieved 
mostly  due  to  formal  analysis  of  the  system  under  test,  rather  than  by  the 
statistical  approach  itself. 

4.3  Analysis  and  Proof 

All  testing  methods  we  reviewed  have  shown  clearly  that  in  order  to  obtain 
meaningful  test  set-ups,  a  great  deal  of  effort  should  be  invested  in  analysing 
and  formally  proving  properties  of  the  tested  program.  The  earlier  this  effort  is 
invested  during  the  development  cycle  the  more  benefits  can  be  gained:  by  better 
phrasing  of  the  problem,  ability  to  predict  the  solution’s  behavior,  and  pin¬ 
pointing  bottle-necks  and  weak  points.  If  such  attitude  is  adopted,  proof  systems 
should  give  answers  to  all  system’s  phases,  from  early  model  to  the  detailed 
source  code,  proving  correctness  of  solution  strategy  as  well  as  correctness  of 
the  implementation.  Since  the  main  interest  of  this  work  is  real  time  programs, 
the  main  part  of  this  section  will  concentrate  on  systems  that  try  to  verify  and 
prove  timing  properties. 

4.3.1  Process  Based  Model  Analysis 

Categories 

There  are  two  major  approaches  in  analysing  and  demonstrating  program’s 
properties  without  execution,  assuming  a  process  based  model  has  been  prefered: 

•  Proving  that  the  program  satisfies  certain  criteria,  or  performs  according 
to  given  specifications. 

•  Proving  by  analysis  certain  structural  properties  of  the  model. 

The  following  example  will  demonstrate  these  kinds  of  analysis. 

Example:  Flow-graphs 

Two  bi-digraphs  are  used  to  model  the  system  *.  A  control  flaw-graph  describes 
the  structural  behavior  of  the  program,  and  the  control  flow  during  execution, 
while  a  data  flow-graph  (corresponding  to  each  execution  sequence)  describes 
the  data  behavior  during  this  execution  [22].  In  the  control  graph:  the  ver¬ 
tices  represent  control  point s,  and  the  directed  arcs  represent  action*  or  control 
transitions.  In  the  data  flow-graph:  there  are  two  types  of  vertices;  data  items 
and  operations.  The  vertices  are  connected  by  directed  arc*  describing  the  data 
flow.  A  data  flow-graph  corresponds  to  an  execution  sequence  S  =  (ai,..,an) 

‘Modeling  s  system  In  »  flow-graph  method  Is  described  in  section  3.4. 2  of  this  document. 
A  brief  review  is  repeated  here. 


in  the  control  flow-graph,  by  attaching  to  each  arc  Oi  a  mapping  of  input  vari¬ 
ables  (Xi,..,Xk)  into  output  variables  (Vi, Ym).  This  functional  relation  is 
the  vertex  of  type  “operation*  which  appears  in  the  graph.  The  graph,  which 
may  be  very  large  in  case  of  a  complex  program,  may  be  reduced  by  means  of 
abstraction  levels,  merging  data  items  to  vectors,  and  sequential  actions  into 
control  segments.  This  graph  may  be  used  to  demonstrate  structural  properties 
and  to  verify  some  performance  ones. 

•  Independent  data  items  may  be  detected,  and  point  the  distributed  imple¬ 
mentation  that  requires  less  communication  traffic.  The  problem  becomes 
a  partitioning  problem  which  requires  that  the  number  of  arc-cuts  is  min¬ 
imised. 

•  Each  execution  sequence  with  its  corresponding  data  flow-graph  encoun¬ 
ters  all  the  information  needed  for  numerical  error-bound  analysis. 

Deficiencies 

Flow  graphs  and  more  advanced  tools,  such  as  SPECK  [30],  share  the  same 
deficiencies.  Program  correctness  verification  is  very  difficult  to  implement,  and 
more  difficult  to  understand.  Timing  properties  are  either  ignored  at  all  or 
receive  a  simple  and  fruitless  analysis.  The  statistical  nature  of  inputs  is  not 
considered,  and  average  and  peak  performance  evaluation  is  not  provided. 

4.3.3  Finite  State  Automata  Model  Analysis 

Graph  Model  Analynin 

The  usage  of  graph  models  to  describe  problems  and  solutions  has  spread  dur¬ 
ing  the  last  decade.  The  graph  models  were  described  in  chapter  2  of  this 
document,  and  this  section  will  concentrate  in  their  analysis  power.  This  mod¬ 
eling  provides  information  about  the  structure  of  the  solution,  as  the  process 
based  method  does.  Yet,  more  properties  can  be  analysed:  safeness,  bound¬ 
edness,  liveness  (deadlock  freedom),  reachability  of  states,  equivalence  between 
solutions  (optimisation),  as  well  as  timing  properties. 

Various  graph  methods  have  been  developed  and  used.  Some  examples  are 
the  bipolar  synchronisation  graph,  the  R-nets  in  SREM  [4],  and  the  Petri  nets. 
Some  of  them  share  a  lot  in  common,  and  some  look  as  an  augmentation  of 
others.  The  next  pages  will  describe  a  combined  use  of  stochastic  properties 
and  thq  Petri  net s. 

Stochastic  Petri  Network  (SPN)  Model  Analysis 

Classic  Petri  nets  [31]  do  not  contain  any  timing  properties  concerning  the 
behavior  of  the  finite  state  machine  they  describe.  The  reachability  set  which 
is  produced  when  analysing  the  net,  describes  all  possible  states  the  machine 
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can  reach.  If  this  model  ia  extended  (27],  by  assigning  probabilistic  firing-rates 
to  transitions,  the  net  becomes  isomorphic  to  an  homogeneous  Markov  process, 
dne  to  the  countability  of  the  markings  and  the  memoryleas  property  of  the 
firing  rate.  Some  definitions  summarise  the  SPN. 

•  PN  =  (P,  T,  A,  M )  ,  A  Petri  network. 

•  SPN  =  (P,  T,  A,  M,  <J)  ,  PN  extended  to  SPN. 

•  P  =  {pi, ..,  Pn}  ,  Places  -  drawn  as  circles. 

•  T  *=  {ti, ..,  tm}  ,  Transition  -  drawn  as  bars. 

•  A  s=  {P  x  T}  u  {T  x  P}  ,  Input  and  output  arcs. 

•  Q  —  i  Average  transition  rates,  for  the  exponentially  dis¬ 

tributed  firing  times. 

•  M  =  {mi, ..,  m„}  ,  Initial  marking  -  drawn  as  dots.  M  :  P  — ►  M  (the 
natural  numbers),  M(p/)  =  m/J  =  1, ..,  n. 

•  Set  function  I(t)  =“  {p  :  (p,  t)  S  A}  ,  Input  places  for  transition  t. 

•  Set  function  0(t)  =  {p  :  (t,  p)  6  A}  ,  Output  places  for  transition  t. 

Molloy  ([27])  proves  that  any  finite-place,  finite-transition,  marked  SPN  is 
isomorphic  to  an  one-dimensional  discrete-space  Markov  process,  concerning  the 
marking  sequence.  Hence,  in  addition  to  all  properties  that  can  be  proved  using 
a  regular  Petri  net  (as  describing  concurrency,  contention  and  synchronisation, 
analysis  of  deadlocks  boundedness  and  self  regulation),  the  SPN  provides  capa¬ 
bilities  of  performance  verification:  analysis  of  average  delay,  average  through¬ 
put  etc.,  using  queueing  theory  (23].  Consider  the  following  simple  example  (see 
Figure  4.1)  which  demonstrates  the  combined  use  of  the  above  methods. 

Example:  Given  the  following  SPN : 

1.  The  places  and  transitions  sets: 

•  T  =  (t|, ..,  tj)  . 

•  P  —  {Pli-iPs}  . 

2.  The  connections: 

•  ^(*1)  *  (Pi}.0(*i)  =  (Pa.Ps)  • 

•  Hh)  =  (M.Ote)  =  {p4}  . 

•  /(*s)  =  {P3},0(t3)  =  {ps}  . 

•  /(t4)  =  {p4},0(t4)  =  {p3>. 
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•  ■  {P4.P#}iO(*8)  *  {pi}  . 

3.  The  firing  probabilities:  91  =  2, 93  =  1, 93  =  1.  ?4  =  3, 95  =  2. 

4.  The  initial  marking:  M  -  {mi  =*  1;  m/  =  0,  /  €  2.. 5}. 

Solving  the  above  system  using  Molloy’s  method  is  performed  as  follows. 

1.  Analysing  the  net  structure,  the  transitions  can  be  characterised  as: 

•  (<6.*i)  -  Sequential. 

•  (*3»  *3)  _  Parallel. 

•  (*4>  t&)  -  Contention. 

•  1 1  -  Fork,  ts  -  Joint. 

2.  The  reachability  set,  describing  the  "token*  occupancy  in  the  places  set 
(i.e.  the  marking)  Af<  =  (pi.Pa.ps.Ps.Ps): 

•  Mi  m  (1,0, 0,0,0)  . 

•  Afa  =  (0,1, 1,0,0). 

•  M9  =  (0,0, 1,1,0). 

•  (0,1, 0,0,1). 

•  Af5  =  (0,0, 0,1,1) . 

A  set  of  five  reachable  marking  states. 

3.  Solving  the  ergodic  Markov  chain  (as  in  [23]): 

•  2Pr[Ml]  =  2Pr\MS\  . 

•  2Pr(M2|  =  2Pr(Ml]  +  3Pr(A/3]  . 

•  4Pr(Af3]  =  Pr{Af 2]  . 

•  Pr[M4]  -  3Pr(W5j  +  Pr\M2\  . 

•  SPr[M5]  m  Pr\M4\  +  Pr(AT3j  . 

•  Pr[M\\  +  Pr\M2\  +  Pr|M3]  +  Pr[Af4)  +  Pr[Af  5|  =  1  . 

4.  The  marking  steady  state  probabilities: 

•  Pr[Ml]  -  0.1163  . 

•  Pr[M2\  =  0.1860  . 

•  Pr\M 3]  =  0.0468  . 

•  Pr\M<)  *  0.5349  . 

•  Pr[W5]  =  0.1163  . 


5.  Calculating  the  probabilities  of  token  occupancy: 

•  Pr[mi  «  1)  *  0. 11M  -  Pr[hi\\  . 

•  PrJmj  -  1]  -  0.720®  -  Pr\M2)  +  Pr|M4]  . 

•  Pr(m3  -  1]  *  0.2325  -  Pr[M2\  +  Pr\Mi\  . 

•  Pr[m 4  *  1|  *  0.1628  -  Pr(^3)  +  Pr[MS\  . 

•  Pffm#  -  1]  .  0.6512  -  Pr[M4\  +  Pr[M5\  . 

6.  Thu  probabilities  calculated  above  depend  on  tbe  reachability  set,  which 
itaelf  depends  on  the  initial  marking.  If  the  initial  marking  wee  2  tokens 
in  pi,  the  reachability  set  would  consist  of  14  states,  and  3  tokens  in  pi 
would  produce  30  states. 

7.  The  ergodkity  of  the  chain  allows  using  flow  balance  technique  and  Little's 
law  for  average  performance  analysis.  In  this  example,  the  average  delay 
time  can  be  calculated  as  follows.  TVansition  tj  can  be  enabled  only  if 
Pi  contains  a  token,  hence  utility(ti)«0.1163.  Having  *  2  ,  implies 
an  average  token  flow  of  0.2326  tokens  per  time  unit  in  pi .  Since  tj  is  a 
fork,  the  average  token  flow  in  the  parallel  paths  is  doubled  (0.4652),  and 
reduced  again  in  the  joint  t«.  Since  the  system  conserves  tokens  (neither 
destroy  nor  produce),  we  can  apply  Little’s  law,  knowing  the  average  flow 
rate  in  each  branch  from  above, 

•  r-  -  • 

•  Nam  "  52) ml  mIm  m  1.7674  . 

•  Tm  m  1.7674/0.4652  *  3.8  time  unite. 

Another  approach  (Generalised  Stochastic  Petri  Nete)  is  introduced  in  [3]. 
Combining  this  approach  with  product  form  queucinq  network  theory  provides  a 
tool  for  performance  verification  for  non-classical  queueing  constructs  (7).  This 
combination  can  also  be  used  to  find  upper  and  lower  bounds,  as  an  approxi¬ 
mation  for  non- product- form  systems  performance. 

4.3.3  Theorem  Proving  Techniques 

Proving  in  General 

Hoare’t  axiomatic  approach  was  adopted  for  proving  programs  in  various  proof 
systems.  This  approach  was  extended  for  distributed  systems  [29],  and  consti¬ 
tutes  a  base  line  for  other  proof  systems,  as  for  CSP  proving  [6j  and  others. 
There  are  some  major  difficultiee  using  the  axiomatic  approach: 

•  Time  dependent  proportion  of  concurrent  systems  (concurrency,  mutual 
exclusion)  are  difficult  to  specify. 
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•  Finding  invariants  for  complex  systems. 

•  Simplification  of  long  expressions  art  ia  most  timss  tedious. 

The  following  paragraph  is  dealing  with  aa  approach  which  trios  to  solvt  those 
probloma. 

Kmt  Baasd  Modal 

Emt  baaod  modal  of  a  system  3  (|9j),  ooparates  tho  systems’*  pro  port  ioo  into 
two  major  cateforias:  kcheeter  which  maialy  coacorns  tho  external  view  of  tho 
system,  aad  structure  which  reflect*  tho  ia  tonal  view  of  tho  system.  Proving 
ths  corroctaoas  of  a  system  is  translated  iato  a  consist  ancy  chock  botwoon  tho 
behavior  aad  tha  stractnro.  Orthogonality  batwooa  pro  port  ioo  allows  verification 
of  tach  indapondontly,  aad  thorsby  avoids  ‘exponential  state  explosion*  whon 
coming  to  derive  test  sate.  Tho  modal  is  constructed  from  events  and  their 
relations: 

1.  Aa  soon*  is  aa  ins  tents  noons  (takas  saro  time)  atomic  (happens  completely 
or  not  at  all)  state  transition  in  tha  system’s  computation  history. 

2.  Tima  ordering  is  achieved  with  tha  precede  (— ►)  relation,  which  is  a  partial 
ordering  foaad  also  in  (24).  Event  si  precede  event  s2  (  si  -*  *2  )  if: 

e  si,  e2  an  events  at  tha  same  process  (aa  autonomous  computation 
node,  having  its  own  local  clock)  aad  si  comas  before  s2,  or 
o  si,  s2  an  avoate  at  different  processes,  aad  si  is  a  ssn d  msssags  event, 
aad  s2  is  a  receive  event  of  tha  wy  same  message. 

This  partial  ordering  ensures  that  si  — »  s2  implies  that  si  happens  before 
s2  by  say  measure  of  time.  (It  is  not  IFF  t).  The  ordering  is  transitive, 
irreflexive  aad  anti-symmetric. 

3.  Causality  ordering  is  achieved  with  the  suable  (— w)  relation,  which  is  also 
a  partial  ordering,  and  is  defined  as  follows: 

Event  cl  enables  event  *2  (  *1  *2  )  IFF  the  existence  of  event  *1  will 

cause  occu runes  of  even  s2  in  the  future. 

This  ordering  is  also  transitive,  irreflexive  and  anti-symmetric. 

This  model  allows  program  verification  in  a  theorem  proving  fashion,  using 
the  model's  definitions  combined  with  first  order  predicate  calculus.  Orthogo¬ 
nality  of  relations  is  used  to  simplify  proof  procedures  which  are  complex,  yet 
abstraction  levels  must  be  enforced  to  deal  with  very  large  systems.  The  system 
interacts  with  its  environment  by  exchanging  messages  through  unidirectional 
ports,  in  which  local  history  is  ordered  locally,  and  the  bskaaior  properties  are 
specified  and  measured.  Some  good  property  verifications  are: 

*The  event- based  model  ia  described  in  section  I.S,  and  a  brief  deecription  is  repeated  here. 
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•  Concurrency  of  events  el  end  <2  is  proved  IFF  — >(«1  — *  e2)  ud  — *(«2  — »  el). 

•  /iNMM  of  mat  is  proved  applying  an  *  an  able's  sequence  to  the  initial 
state.  It  guarantees  that  event  will  eventually  happen,  (proving  starvation 
freedom  or  meesage  delivery)  bnt  more  strict  timing  requirements  cannot 
be  proved  by  this  proof  system  which  provides  only  partial-order  relations. 

Seal  Time  Logic 

Another  event  based  model  is  introduced  in  [21],  in  order  to  verify  safety  prop- 
arties  of  a  real  time  system.  The  model  consists  of  events,  actions,  causality 
relations,  and  timing  constraints.  The  model  is  expressed  in  a  first  order  logic, 
describing  the  system  properties  as  well  as  the  system's  dependency  on  exter¬ 
nal  events.  The  Real  Tima  Logic  system  (RTL)  captures  time  with  an  event 
occurence  function  denoted  "O'.  This  function  assigns  time  values  to  event 
occur ances,  while  the  constraints  and  the  scheduling  disciplines  are  restrictions 
imposed  on  the  function.  RTL  uses  three  types  of  constants: 

1.  Action  constants  -  may  be  primitive  or  composite.  In  a  composite  con¬ 
stant  precedence  is  imposed  by  the  event-action  model  using  sequential  or 
parallel  relations  between  actions. 

2.  Fee  at  constants  -  are  divided  to  throe  dieses.  Start /stop  events  describe 
the  initiation/ termination  of  an  action  or  subset  ion.  Transition  events 
are  those  which  make  a  change  in  state  attributes  (i.e.  a  change  in  an 
smart  ion  about  the  state  of  the  real  time  system  or  its  environment). 
External  events  are  those  which  cannot  be  caused  by  the  system,  but  can 
impact  system  behavior. 

S.  /nteyers  -  assigned  by  the  occur ance  function,  to  capture  time,  and  used 
to  denote  the  number  of  an  event  occurence  in  a  sequence. 

Assertions  about  the  physical  state  of  the  system  over  time  are  translated  into 
elyclfutc  relations,  involving  the  occurences  of  the  appropriate  transition  events. 
Stmt*  predicates  are  used  as  a  aotaiioaal  device  for  asserting  truth-values  to  state 
attributes  during  a  time  interval. 

A  set  of  axioms  can  be  derived  from  the  event-action  model  of  the  system  by 
applying  an  automatic  translation  to  the  system  specification.  This  translation 
describes  the  relations  between  actions  and  their  start /stop  events,  the  sporadic  * 
and  periodic  events  constraints,  as  well  as  the  causal  relations  which  may  initiate 
a  transition  event.  Artificial  constraints  may  be  added  in  order  to  prevent  the 
scheduler  from  executing  actions  that  are  not  counted  towards  meeting  specified 
timing  constraints  (i.e.  not  required),  especially  when  utilisation  of  resources  is 
lees  than  100%. 

A  timing  property  of  a  system  (an  RTL  assertion)  is  expressed  by  showing 
that  there  is  no  occur ance  function  which  is  consistent  with  the  system  speci¬ 
fication,  in  conjunction  with  the  complement  of  this  particular  property.  The 
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mechanism  to  achiavu  it  is  the  deductive  rsfolehou.  Am  important  characteristic 
of  RTL  allows  using  procedures  a>d  ia  Pmbsrgo  Arithmetic:  aa  RTL  formula 
coasiets  of  only  algebraic  relatioas  aad  state  predicates  coaaected  by  first  order 
logic  operators. 

Aa  advantage  of  RTL  is  the  uniform  way  ia  which  diffareat  types  of  con- 
straiats  caa  be  expressed,  by  ■»“«■  of  algebraic  relatioas  of  event  occuraaces. 
Yet,  it  is  weak  ia  providing  hierarchy  levels  of  abetractioa,  which  are  accessary 
to  simplify  system  aad  to  relate  the  implemeated  eolation  to  the 

requirements  specification.  Since  this  approach  is  very  young,  it  will  probably 
be  developed  ia  the  fetors  to  provide  these  features. 

4.3.4  Timing  PropertUm  analysis 

Weakest  Pro  condition  and  Predicate  Transformers 

A  very  interesting  approach  is  iatrodaced  by  V.  Haase  (17)  for  verification  of 
real  time  behavior  of  programs.  Throe  major  —amptioae  are  the  baas  of  this 
approach: 

1.  The  program  consists  of  parts  which  an  seqaeatial  and  parts  which  an 
parallel.  The  seqaeatial  parts  an  constructed  from  Dgkstru’s  guarded 
commends,  aad  the  parallel  coaetructa  (PARC*)  an  CSP-liks  parallel  ia* 
terpretatioa  of  the  guarded  commands. 

2.  The  weakest  ywcsskiKos  predicate,  Sep* ,  provides  the  execution  time 
properties  to  the  program  parts: 

e  Ia  case  of  s  simple  statement  (S),  Le.,  not  aa  iterative  ear  a  con¬ 
ditional  one  -  whom  execution  time  caa  be  defined  aa  the  non- 
interrupted  execution  tune  needed  for  the  implementing  processor 
-  the  wsahsei  precondition  caa  be  interpreted  as  "the  latest  starting 
time*  t  to  meet  deadline  T  with  statement  execution  time  t, 

vp(S,t  <T)  -  t<T-t. 

e  In  caae  of  aa  action,  i.e.,  a  noa- interrupted  sequence  of  sequential 
statements  (action  •  5t; 5«), 

wp( action,  t  <  T)«  wp(5i,  wp(Sa,  ,.wp(Sn,  R)  .)) 

-«<r-n.,t« 

-  t  <  T  -  t«n«m 


S.  Since  execution  ia  also  input- data- dependent,  and  not  only  hardware  de¬ 
pendent,  this  property  (which  appears  ia  branching  points  aad  ia  iteration 
decision)  is  characterised  with  Dijksira’s  pndicst*  tmae/ormcr  rule 


twttai  *  /(fl.".d«) 
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where  dl , <L,  are  input  data  of  action. 

Ia  practice  om  caa  distinguish  two  caaee: 

•  when  f(..)  ia  a  constant  or  vary  simple,  than  execution  time  can  be  eval¬ 
uated  explicitly  prior  to  execution. 

•  when  }(..)  is  comparatively  complex,  then  an  upper  hound  can  be  esti¬ 
mated,  and  if  the  bound  is  passed  during  execution,  a  special  process  (as 
Nratch-dog” )  may  re  evaluate  necessary  updates. 

Thau  Behavior  of  Sequential  Programs 

Haase  suggests  a  method  to  aaalyae  sequential  programs: 

1.  Transformation  into  guarded-command  notation;  Transforming  the  non¬ 
iterative  and  non-branching  parts  is  done  as  described  above,  while  deriv¬ 
ing  the  weakest  preconditions  appropriately.  Then 

•  Conditional  statements  are  transformed  into  Dijkstra’a  IF: 

IF 

pi  — *  action! 

9n  —  action* 

FI 


Deriving  the  weakest  precondition: 

wp(ir,t  <T)m  (3j  =  0y)  and  (Vt :  gj  —  t  <  T  -  t.***.,). 

•  Iterative  statements  are  transformed  into  Dijkstra’s  DO: 
DO 

0i  —*  octioni 


0»  -*  action* 
OD 


Deriving  the  weakest  precondition: 
vrp(DO,t  £  T)  -  (3*  >  0  :  #fc(t  <,  T ))  ,  where 
*o(t  <,  T)  -  (t  <  T)  AND  — <(3y  :  9i),  and 

_ Rkltm-wpiir+.He-dt  <  t))  or  /r0(t  <  r) » . 

denotes  the  same  guarded-command  set  with  assumed  IP/FI  brackets. 
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2.  Afar  t he  program  w  written  in  an  equivalent  guarded  commands  notation, 
the  yrofrssu  prscowWitten  ku  to  b«  constructed,  applying  the 

— qua ntial  rules  introdncad  abort. 

S.  Rvsluatc  the  program's  wp:  Ths  evaluation  of  tba  program’s  weakest  pro- 
condition 

wp (program,  t  £  2*)  -  wp(Slt  ,.wp(DO,  \*p(IF,  t  <  T))..) 

in  canted  out’insids  first’ .  Starting  with  th«  inner  moat  wp,  ite  waak- 
aat  pracondition  is  evaluated,  than  substituted  in  tha  following,  until  the 
outer  moat  is  evaluated,  and  thereby  provides  tha  whole  program's  lateet 
starting  time  to  mast  tha  required  deadline. 

Time  Behavior  of  Parallel  Programs 

Parallel  programs,  constructed  with  PARCe,  can  be  analysed  with  predicate 
transformers  as  trail.  A  vary  important  assumption  is  taken  in  tha  constructing 
phase,  that  tha  guards  variables  are  mutually  exclusive.  This  yields  a  vary 
«imiW  guarded  commands  set,  yet  tha  rani  time  is kavtor  is  dt#cr*nt  from  tha 
sequential  programs. 

•  Parallel  condition  construct,  denoted  IF-PARC,  is  canted  out  aa  follows: 
PAR- IP 

gi  —  action] 

II- 
II  • 

lift.  —  action* 

PAR-PI 


Semantics  are  defined  by  the  formulas 


and 


(Ri)and(Ri)..and(R*)  —  R 


v>p(IF  ~  PARC,  Ri-.andR* )  * 

(Vi  €  l..n) :  (ft  —  wp( action*,  Aj)and-’(ft)  —  R*)  —  wp(IF  -  PARC,  R). 

All  Rj  are  substituted  by  t  <  T,  and  false  g*s  are  omitted  (not  contributing 
to  execution  time).  The  latest  starting  point  is  therefore 

wp(IF  -  PARC,  t<r)«Vi:ft-(t<T  - 
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•  PnnlUl  iterative  construct,  denoted  DO-PARC,  is  carried  oat  u  follow*: 


PAR-DO 

gi  — *  action  i 

II  • 

II  • 

II  9»  -*  action. 

PAR-OD 


Semantics  identity  between  DO  and  DO-PARC  allows  using  parallel  struc¬ 
ture*  as  well: 

wp(DO  -  PARC,  t  <  T)  -  (3*  >  0  :  H„(t  <  T)). 

Bat  the  evaluation  is  different 


DO:  execution  time  =  t»  +  t„ 

DO-PARC:  execution  time  *  maift.,  t.y). 

A  method  to  evaluate  the  latest  starting  point  is 

1.  Each  scfsoM  is  repressnted  by  a  sector  m  the  state  space  of  PARC*. 

2.  Establish  the  paths,  La.  the  sequsneas  of  nctions,  leading  from  assumed 
pre-states  to  given  post-states  af  the  whole  activity. 

S.  Consider  the  folkwing  cases: 

Cane  n.  If  the  path  between  any  two  states  is  unambiguous,  then  the  sum 
of  the  intermediate  execution  times  of  the  steps  is  taken  into  account. 

Case  b.  If  the  path  is  ambiguous,  then  determine  partial  sequences  that 
can  be  « sc  hanged,  and  then  maximum  execution  time  of  the  partial 
sequences  is  taken  into  account. 

4.  If  in  the  example  above  we  assign  equal  execution  times  to  the  actions  of 
Pi  (every  vertkal  step),  denoted  by  tv,  and  equal  execution  times  to  the 
actions  of  P}  (every  horisontal  step),  denoted  t*,  we  can  conclude  (see 
Figure  12): 

4  to  Sioctim,  — *  U 

5  to  l:acti0fi,|jaction<  — *  max(t*,tv) 

1  to  fraction,  — *  t. 


Pi 


Pi 


Figure  4.2:  Paths  Example. 

Therefore,  the  calculation  of  the  weakest  precondition  is  restricted  by 
t  <  T  -  t»,  - 1,  -  mai(tfc,  t»). 

Hesse’s  approach  gives  e  tool  to  deal  with  medium-complex  real-time  pro¬ 
grams,  yet  when  dealing  with  very  complex  systems,  one  may  find  it  very  hard 
to  analyse.  In  order  to  solve  this  situation,  he  suggests  the  use  of  a  dynamic 
checking  of  (estimated)  deadline,  by  adding  a  parallel  control  action.  This  dy¬ 
namic  scheduling  approach  is  very  similar  to  the  Latency  Scheduling  we  reviewed 
in  chapter  2. 

4.S.5  Operational  Analysis 

Performance  evaluation  using  (12]  operational  analysis  provides  a  quantifying 
tool  to  obtain  average  performance  properties.  Using  a  routing  connection  be¬ 
tween  service  c enter*  (C.S.)  whose  performances  are  given,  one  can  obtain  the 
performance  of  a  specific  system  configuration  in  steady  state.  It  is  done  assum¬ 
ing  job  flow  balance,  and  applying  simple  statistical  tools  to  derive  properties 
which  one  cannot  obtain  by  oboervation  (external  direct  measurement).  Al¬ 
though  these  properties  may  be  derived  by  the  models  we  reviewed  so  far,  it 
seems  that  this  evaluation  technique  covers  a  field  which  all  the  other  papers 
(mentioned  in  this  review)  have  not  dealt  with.  This  is  the  retourcee  eaturation 
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problem,  which  arises  due  to  the  resources  bounded  utilisation,  which  produces 
the  bottle-neck  phenomena.  Analysing  the  system’s  performance  must  take  into 
account  the  simple  fact  that  service  centers  may  be  ‘pushed*  only  up  to  their 
utilisation  upper  bound,  and  therefore,  the  weakest-point  in  the  system  config¬ 
uration  will  slow  down  all  other  parts. 

In  order  to  describe  the  bottle-neck  analysis,  the  notation  used  in  [12]  will 
be  used  in  the  following  paragraph.  Let 

•  U,  be  the  utilisation  of  S.C.  t,  defined  as  its  “busy  time*  over  an  observa¬ 
tion  period  T. 

•  X,  be  the  throughput  of  S.C.  t,  defined  as  the  number  of  job  “departures” 
from  it  over  an  observation  period  T. 

•  V{  be  the  visit  ratio  of  S.C.  t,  defined  as  its  throughput  part  in  the  whole 
system  throughput  (equals  X,/X0). 

•  Si  be  the  mean  service  time  of  S.C.  i,  defined  as  the  portion  of  its  busy 
time  served  to  each  customer  (i.e.  (TxUi)/(TxXi)  ).  Hence,  Ui  =  XixS, 

•  Rib*  the  mean  response  time  of  S.C.  i,  and  let  Ro  denote  the  whole  system 
response  time  for  a  single  customer. 

The  bottle-neck  analysis  is  done  assuming  a  device  has  reached  its  highest 
utilisation,  and  let  this  device  be  denoted  by  the  subscript  b.  Hence,  Ub  —  1. 
In  order  to  determine  which  S.C.  is  b,  we  have  to  compare  the  utilisations  of 
all  S.C.s,  and  pick  the  highest  one,  since  increasing  the  customers  number  will 
increase  utilisations  of  all  S.C.s,  until  one  of  them  will  reach  1,  and  the  first  to 
do  so  will  be  the  one  with  the  highest  Ui  to  begin  with. 

Ui/Uj  =  (*  x  Si)/(X,  x  Sf) 
division  and  multiplication  by  Xa  gives 
Ui/U,  =  (Xi  x  Si/X0)/(X}-  x  S,/Xa) 
and  since  Xi/Xa  =  Vi  then 
Ui/U V  =  (Vi  X  Si)/{Vj  X  S}) 

Then,  in  order  to  pick  the  highest  utility, 

VbxSb  =  MAXi  (V  x  Si) 


For  saturation  state  of  the  bottle-neck  S.C.  the  following  will  hold: 

Oj*l  *■>  Xb  =  1  /  sb 
vb  -  Xb/X0 
Hence, 

X0  -  l/(Vs  x  Sb) 


Due  to  N  =  N,  customers  in  the  system. 


Yet,  for  the  single  customer  case,  Xa  =  1  /Ra  due  to  N  =  1  customer  in  the 
system. 

Plotting  a  graph  of  the  system  throughput  versus  the  number  of  customers 
in  the  system,  we  have  the  two  points  (for  N  =  1  and  N  =  N.)  with  their 
corresponding  throughput,  to  construct  the  asymptotes  which  serve  as  an  upper 
bound  to  the  systems  throughput.  The  saturating  N  can  be  calculated  as 

N./l  =  (1/Vfc  x  Sb)/(1/R0) 

for  a  system  without  delay. 

Hence, 

N.  =  R0/(Vb  x  5b). 

The  results  of  the  latter  analysis  are  based  on  broad  assumptions:  mean 
service  time  for  all  customers,  similar  demands  of  service  within  time,  etc.  No 
peak  analysis  can  be  derived  from  them,  yet  they  form  a  performance  bound 
that  has  to  be  considered  when  the  system  is  evaluated. 

4.4  Simulation  As  Verification  Tool 

4.4.1  Classes  and  Aims 

One  can  distinguish  two  major  classes  of  simulations  that  are  used  to  verify 
properties  of  a  real  time  program: 

1.  Simulation  of  the  system  under  test  itself. 

2.  Simulation  of  a  plant /load  that  the  system  meets  as  its  “real  world*. 
There  are  various  reasons  to  simulate  the  program  itself: 

•  During  the  first  phases  of  the  design,  it  helps  to  verify  basic  properties  of 
the  model  used,  i.e.  the  approach  chosen  to  solve  the  given  problem. 

•  Using  an  approximate  simulation,  one  may  predict  approximate  perfor¬ 
mance  of  the  system,  within  a  certain  confidence  level. 

•  Design  trade-off'  may  be  checked  and  analyzed. 

•  After  the  system  completes  its  development  cycle,  a  detailed  simulator 
may  be  used  to  verify  achievement  of  design  goals,  by  comparing  its  out¬ 
puts  to  the  real  system’s  outputs. 

•  It  may  serve  as  a  good  tool  for  providing  answers  to  “what  if"  questions, 
especially  when  deciding  on  upgrading  the  system. 
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A  detailed  simulator  of  a  system  is  very  expensive  to  develop  [30],  and  the  effort 
invested  in  it  may  lead  to  the  fact  that  it  is  completed  only  after  the  real  system 
is  ready  [5].  A  more  common  simulation  is  a  plant/load  simulator,  which  is  used 
for: 

•  Controlled  measurements  of  the  system  under  load,  making  it  possible  to 
isolate  specific  properties  in  a  specific  environment. 

•  Proving  system  under  test,  when  there  is  a  danger  to  test  it  with  the  real 
plant  (e.g.  control  program  of  a  nuclear  power  plant,  control  program  of 
a  weapon),  if  the  risk  calculations  (see  section  4.2.2)  justify  the  effort  of 
developing  such  a  tool. 

•  A  good  debugging  tool  when  trying  to  reconstruct  a  pattern  that  lead  to  a 
crash  or  a  deadlock,  when  only  partial  information  exists  for  the  analysis. 

The  basic  idea  in  using  simulation  as  a  verification  tool,  is  to  gain  an  advantage 
that  no  test  provides.  A  test  is  constructed  according  to  the  system’s  specifica¬ 
tion.  The  simulation  provides  a  verification  of  the  specification  as  well  as  of  the 
system  under  test. 

4.4.2  Problems  in  Simulation  As  a  Verification  Tool 

1.  Simulation  of  a  large  system  is  rarely  used,  especially  due  to  the  cost 
involved  in  developing  it.  A  good  simulator  of  a  system,  requires  an  effort 
investment  which  is  in  the  same  order  of  magnitude  as  the  development 
of  the  system  itself. 

2.  When  the  risks  of  operating  the  system  are  high,  the  simulator  used  as 
a  test  tool  should  be  highly  reliable,  to  an  extent  even  more  than  the 
system  under  test.  This  means  that  in  addition  to  the  development  cost, 
the  simulator  has  to  be  extensively  used  per  se,  before  being  qualified  as 
a  verifying  tool. 

3.  If  the  design  model  and  the  simulator  are  derived  from  the  same  basic 
assumptions,  a  special  kind  of  errors  may  arise,  called  common  mode  er¬ 
rors:  The  simulator  and  the  system  under  test  are  both  mistaken,  and  the 
errors  are  failed  to  be  detected. 

4.  When  comparing  simulator  results  and  system  results,  discrepancies  may 
be  found.  The  problem  of  deciding  “Who  is  wrong?*  may  be  very  difficult 
to  solve.  One  must  be  very  cautious  not  trying  to  change  the  real  world. 

5.  The  most  difficult  problem  in  simulating  a  large  real  time  system  is  the 
dependency  of  its  performance  on  the  sequence  of  inputs  data.  Since  the 
simulator  is  required  to  perform  as  the  real  system  should,  including  real 
time  properties,  the  complexity  required  from  it  is  of  the  same  level,  and 
sometimes  even  higher. 
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A.v, 


The  problems  described  above  make  simulation  as  a  verification  tool  rarely 
found  when  dealing  with  large  real  time  systems.  Only  in  cases  where  it  is 
unavoidable,  regarding  risk  factors  involved,  a  large  effort  is  invested  in  it. 


i 


Chapter  5 


Conclusion 


This  work  tries  to  review  three  phases  in  the  life  cycle  of  real  time  program¬ 
ming.  Chapter  2  of  this  document  reviews  the  design  phase,  by  introducing 
requirements  specification  techniques,  modeling  methods,  and  basic  approaches 
to  the  design  as  a  whole.  Chapter  3  of  this  document  reviews  implementation 
aspects  of  real  time  programming,  by  introducing  a  disciplinary  approach,  as 
well  as  focusing  on  implementation  aspects  that  concern  the  Ada  language  task¬ 
ing  facilities.  Chapter  4  of  this  document  reviews  the  problematic  aspects  of 
validating  a  real  time  system.  Various  methods  of  testing  are  presented,  as  well 
as  proof  systems  and  simulation  techniques. 

As  can  be  seen  in  the  above  chapters  of  this  document,  methods  that  are 
powerful  in  one  phase,  seem  to  fail  in  another.  For  example,  a  stochastic  ap¬ 
proach  of  any  type  provides  powerful  results  in  verifying  mean  values  of  a  system, 
but  fails  to  serve  as  an  aid  for  overcoming  scheduling  problems  in  the  design 
phase.  This  situation  sometimes  leads  to  a  combined  use  of  some  methods, 
linked  together  by  some  means,  to  provide  a  scheme  which  covers  all  the  as¬ 
pects  (as  in  [5]).  In  this  review,  one  may  find  such  links.  One  of  them  is  the 
Petri  net,  which  can  be  used  in  the  design  ([ll])  with  some  augmentations  ([10]), 
it  can  be  automatically  translated  to  a  program,  with  some  modifications  and 
annotations  ([28]),  and  it  can  also  be  used  to  verify  some  statistical  properties 
([27,3,7]).  Operational  approach  also  tries  to  bridge  the  different  phases  ([35]), 
as  do  the  structured  methods  ([4,22,16]).  Some  theoretical  considerations  ([26]), 
and  disciplinary  recommendations  ([34,18])  may  assure  that  the  combined  use 
of  methods  is  well  coordinated. 

As  stated  in  the  beginning  of  this  paper,  the  objective  here  has  been  to 
describe  the  major  techniques  applicable  to  the  three  phases  in  the  life  cycle 
of  a  real-time  system.  In  this  regard,  we  attempted  to  include  most  major 
techniques  and  trends  for  the  real-time  systems. 
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